Validate SDL directive argument values

[afurm]

Summary

• Add SDL validation for directive argument value types, including custom directive usages.
• Reuse ValuesOfCorrectTypeRule for SDL directive nodes through a directive-aware validation context.
• Add coverage for validateSDL and buildSchema rejecting invalid directive argument values.

Why

Fixes #3912.

SDL already rejects invalid values for built-in directives, but custom directive usages could accept invalid argument values such as @foo(bar: FOOBAR) when bar is declared as String!.

Validation

• npm run lint
• npm run check
• npm run testonly
• npm run prettier:check
• git diff --check

Full npm test was attempted, but the Docker-backed supported-node integration could not run locally because the Docker daemon was unavailable.

[vercel]

@afurm is attempting to deploy a commit to the The GraphQL Foundation Team on Vercel.

A member of the Team first needs to authorize it.

[linux-foundation-easycla]

• ❌ - login: @afurm / name: Andrii Furmanets . The commit (3d631c5) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please submit a support request ticket.

[yaacovCR]

Hi @afurm !

Thanks for submitting this PR.

You wrote:

SDL already rejects invalid values for built-in directives, but custom directive usages could accept invalid argument values such as @foo(bar: FOOBAR) when bar is declared as String!.

I would clarify that prior to this PR:

1. During validation of operations, directives included within those operations have their arguments via ValuesOfCorrectTypesRule.
2. Directive definitions within schemas, including custom schemas, have their arguments checked post-schema construction (when type information from the schema is available) byvalidateSchema().
3. The built-in schema directives @deprecated and @specifiedBy coerce their arguments during schema construction, and should give well-formatted errors if this coercion fails. Even if this could be extended to custom directives, it's not exactly the gap you're filling here as...

...your PR fills an existing gap, for both built in and custom directives meant for use on schema SDL, there is no SDL Validation Rule that forbids invalid arguments, because the typed schema is not yet available. It seems like you cleverly built a schema subset to get around this? Can you describe some more the method you use, and whether there are any dangerous of a potentially invalid schema subset being used by this rule, etc.

Thanks!