Align transports with GraphQL over HTTP specification

[bclozel]

This change has been requested in #1113, #568 and #783 in several forms.

This umbrella issue will consider changes in Spring for GraphQL to better align the HTTP transports behavior with the GraphQL over HTTP specification for the "application/graphql-response+json" media type. The implementation is quite close, but we just need a few changes.

In summary, the behavior difference we need to address between "application/json" and "application/graphql-response+json" response media types is about HTTP response status codes. An HTTP request sent to a GraphQL endpoint is processed in several phases like: authentication, JSON parsing, GraphQL document parsing, GraphQL document validation, GraphQL request execution. Depending on when an error occurs, the HTTP response status behavior will differ:

Error Phase	application/json	application/graphql-response+json
JSON parsing	HTTP 400	HTTP 400
document parsing	HTTP 200	HTTP 400
document validation	HTTP 200	HTTP 400
request execution	HTTP 200	HTTP 200

Also, the "data" key in the response document is only present (but can be null) once we enter the execution phase.

Right now, Spring for GraphQL is using the "application/graphql-response+json" media type by default when clients don't request explicitly "application/json" in the Accept: request header. Because we don't currently fully align with the spec, we will need to introduce this behavior change in a progressive fashion to our library: opt-in at first, then made the default behavior in the future.

This change will mostly impact GraphQL clients that expect an HTTP 200 OK response before they consider reading the body as a GraphQL JSON response. For some early error cases, such clients will also need to consider HTTP 400 Bad Request as long as the response content type is "application/graphql-response+json".

To resolve this issue, we should consider several tasks:

1. Align the MVC variant of the HTTP transport and write dedicated integration tests. Offer this behavior as an opt-in feature.
2. Align the WebFlux variant of the HTTP transport and write dedicated integration tests. Offer this behavior as an opt-in feature.
3. Update the GraphQLClient to be more flexible and decode GraphQL responses even if the server responds with a 4xx response status.
4. Document this behavior difference and guide GraphQL clients in our reference documentation.