Stop relying on apply_selection_set for connectors GraphQL response mapping

[benjamn]

Note

This PR targets the branch for #8073, which is a preview release branch for connect/v0.3-associated features. This PR's branch is targeted in turn by #8143.

While a single JSONSelection string (e.g. the selection argument to a @connect directive) represents everything a particular HTTP endpoint might return, in most cases individual GraphQL operations (especially those generated by the query planner) will ask for fewer fields, and may alias/rename those fields.

Historically (since PR #5635), we've used apply_selection_set in json_selection/selection_set.rs to transform the full JSONSelection into whatever a given operation asks for, including implementing field aliasing within the transformed JSONSelection string. In theory, this selection filtering/transforming should make selection execution less expensive at runtime, but we never implemented transform caching, so the transform was happening for every incoming operation at runtime, probably not improving performance overall.

More importantly, with the advent of abstract types, conditional selections, and more complicated use of -> methods (where changing something about the output would require rewriting input arguments), it is no longer generally possible to accomplish everything we want by transforming the JSONSelection. This limitation became apparent recently when a field that came from within a ->match method was renamed with an alias in the GraphQL query. The renamed field ended up null because the field was not actually renamed in the JSONSelection, because apply_selection_set does not descend into rewriting -> method arguments.

Instead, this PR implements a foolproof backup plan: instead of relying on apply_selection_set alone, we execute incoming GraphQL operations against the JSONSelection mapping results, using knowledge of fragments, aliases, and supertype-subtype relationships from the schema. This means apply_selection_set is no longer responsible for any alias renaming, since all of that is handled later. However, apply_selection_set is still responsible for pruning as much of the JSONSelection as possible, when there are fields we can statically detect are definitely unused.

Another approach here would be to make the JSONSelection::apply_to_path method take an ExecutableDocument and only execute fields that are needed by the operation, so we wouldn't have to transform the selection, but that's an optimization that adds complexity, compared to this PR.

[apollo-librarian]

✅ Docs preview has no changes

The preview was not built because there were no changes.

Build ID: f194957f134fc66b3a668576
Build Logs: View logs

[dylan-apollo]

Does this also impact the response caching stuff that @lennyburdette is working on? Or is that keyed on operation? Would be cool if user(id: 1) { name email} being cached meant that user(id: 1) { name } didn't trigger a fresh request.

[github-actions]

@benjamn, please consider creating a changeset entry in /.changesets/. These instructions describe the process and tooling.

[benjamn]

@dylan-apollo Not sure about the exact cache key inputs (curious to hear from @lennyburdette), but this PR should in principle reduce the total number of distinct JSONSelections produced by apply_selection_set, since aliases are now ignored at this level, which I suppose could be good for caching.