feat: Use standardized gql fragments in queries.js files

[howard-e]

To supersede #876.

I've deviated from the original suggestion of:

I'm down with this. Most fields don't impact query performance so it's totally fine to just query all of them every time. For fields that do impact performance, like tests on TestPlanVersions and testResults on TestPlanRuns, I think it should be divided into two fragments to make accidentally tanking your performance less likely to happen. Something like TEST_PLAN_RUN_FIELDS and TEST_PLAN_RUN_TEST_RESULTS_FIELDS.

I think fields like renderableContent might be preferable to leave off, since they're extremely verbose and "specialty" for specific use cases. If it's there where it's not needed it will definitely make debugging responses harder.

We can manually add them where they're needed.

Mainly because having significantly populated queries per page even if the performance hit was marginal (significant in some cases) became somewhat noisy.

So I did my best to identify common enough existing attributes being requested per page and included them in their own respective client/components/common/fragments/TYPE.js file. Where applicable, I created 2 separate queries for the graphql type (simple and all).

Another oddity about this work is there is an inconsistency between the testPlanVersionResolver and testPlanVersionsResolver which makes using the ...TestPlanVersion fragment throw errors for some queries. It may not be worth resolving now due to the current size of the PR and could be follow up task if it becomes an issue.

This PR is still missing several tests for components to feel confidence in this change, but I would rather not balloon this PR more. In discussing this with @stalgiag, they noted that the missing tests can be done in a follow up PR. So this shouldn't be merged until that work is done (so leaving as draft for now).

[stalgiag]

Very impressed you managed to change this much in place. I gave cross verification between the fragments and the old queries my best shot but obviously there are limits on what a human can accomplish there. As such, I agree that we are going to need additional testing to feel secure here.

For the purposes of this PR as it stands and how it will guide additional work before merging, I like where you drew the boundaries on the fragments. You've struck a good balance between reusability with a limited set of fragments and precision of fetch. Also all of the non-query updates make sense to me including the changes in the testing.

I will wait to mark this approved until we get the additional PRs in but for the purposes of continuing this work, I approve this. I'll reach out to you directly to coordinate writing additional tests.

[stalgiag]

Looks good to me! As I said earlier, I like where the boundaries were drawn and a fragment for TestPlanVersion can be a low priority follow-up.

I am amazed that it passes the new tests on the first try. Well done!