Input Value Validation

[leebyron]

Depends on #3065

Factors out input validation to reusable functions:

• Introduces validateInputLiteral by extracting this behavior from ValuesOfCorrectTypeRule.
• Introduces validateInputValue by extracting this behavior from coerceInputValue
• Simplifies coerceInputValue to return early on validation error
• Unifies error reporting between validateInputValue and validateInputLiteral, causing some error message strings to change, but error data (eg locations) are preserved.

These two parallel functions will be used to validate default values in #3049

Potentially breaking if you rely on the existing behavior of coerceInputValue to call a callback function, as the call signature has changed. GraphQL behavior should not change, though error messages are now slightly different.

[andimarek]

@leebyron question: are you going to validate default argument values of Directive definitions and arguments of applied Directives too?

For example:

# custom Scalar
scalar CacheKey

directive @cached(
  key: CacheKey = {key: "DEFAULT", duration=1000}
) on FIELD_DEFINITION 

type Query {
  hello: String @cached(key: {key: "hello", duration = 500})
}

[leebyron]

Yes both. Though one additional follow up might be necessary.

Arguments of applied directives in operations have always been validated in the ValuesOfCorrectType validator. In schema they never translate into something so they haven't been validated. This seems like an easy thing to fix.

Directive definition argument default value validation is in the RFC spec change and included in the last PR in this stack

[yaacovCR]

Merged rebased version of this PR as #3813.