feat: execution for fragment arguments syntax

[JoviDeCroock]

This implements execution of Fragment Arguments, and more specifically collecting-fields and replacing the variables in a fragment-definition with values coming from the fragment-spread, as described by the spec changes in graphql/graphql-spec#1010.

This is a 2024 update of graphql#3835 where all discussions have been carried over in code comments, they are highlighted already as review comments here as well.

This PR splits out the execution part so we can look at that in detail, I will pause here as the fragment-keying remarks will most likely have quite an impact on the validation changes.

[github-actions]

Hi @JoviDeCroock, I'm @github-actions bot happy to help you with this PR 👋

Supported commands

Please post this commands in separate comments and only one per comment:

• @github-actions run-benchmark - Run benchmark comparing base and merge commits for this PR
• @github-actions publish-pr-on-npm - Build package from this PR and publish it on NPM

[mjmahone]

Yeah I realized (after I started) that we do need to preserve a two-layer “stack” of variables, a la the refactored context you’re describing. Substitution doesn’t cut it: I can’t remember all the details for WHY substitution doesn’t work (sounds like you’re learning them though!).

Yes it would be a pretty large refactor, but I think that refactor is essentially required to make fragment arguments good.

[JoviDeCroock]

@mjmahone the refactor is largely done in https://github.com/JoviDeCroock/graphql-js/compare/fragment-args-execution-2024...JoviDeCroock:graphql-js:collect-fields-alternative?expand=1

[yaacovCR]

Overall I wonder if it would be nice to have some common GraphQLArgument/GraphQLSignature type similar to #7 that could unify some of the above logic.

[yaacovCR]

If it helps at all, I have rebased this branch on current main: https://github.com/yaacovCR/graphql-executor/tree/fragment-args-execution-2024-rebased

[yaacovCR]

Here is a commit that implements some parallel changes to what I suggested in the TypeInfo branch with precompiling the fragment variable signatures....

yaacovCR@e5744fc

Also includes greater code reuse of getArgumentValues, but presently requires some JavaScript specific changes around non-provided variables, previously they did not appear at all in the args array, now they need to be present but undefined, so the code path for supplying the default field value takes precedence over the operation default value

[yaacovCR]

but presently requires some JavaScript specific changes around non-provided variables, previously they did not appear at all in the args array, now they need to be present but undefined

I was able to fix this on my scratch brainstorming branch: https://github.com/yaacovCR/graphql-executor/tree/execution-suggestions

[yaacovCR]

TODO: rebase last 1 commit on fragments args syntax

branch https://github.com/yaacovCR/graphql-executor/tree/execution-suggestions has that commit rebased on main and then one additional commit showing you one potential set of changes that would be responsive to the feedback i am trying to give.

Basically, in that branch:

1. we reuse getArgumentValues for field arguments and fragment arguments
2. we do not coalesce fragmentVariablesValues and regular variableValues into a single map, but just pass around both to the relevant functions
3. we have an experimental prefix for the function that changes signature (experimentalGetArgumentValues()), everything else just gets optional arguments
4. we do not store fragmentVariables in the context
5. we have a separate type GraphQLVariableSignature that we use whenever we encounter a variable (this last item actually fixes a trivial bug with one-of)