Prior to this commit, the `GraphQlObservationInstrumentation` would
organize the parent/child relationship between data fetcher observations
by setting the current observation under a well-known key in the global
GraphQL context.
In some cases, the order of execution and the scheduling of operations
does not reflect the actual operation hierarchy as defined by the
GraphQL `ExecutionStepInfo`. This would result in traces where data
fetching operations are set with incorrect parent/child relationships.
This commit ensures that data fetcher observations have their parent set
with the expected one, by keeping track of active observations and using
the `ExecutionStepInfo` path as a key.
Fixes gh-676
Prior to this commit, the request execution observation would have a
context of type `RequestReplyReceiverContext` to directly deal with
tracing propagation at the transport level. This approach doesn't work
anymore as the parent observation is not properly set on the resulting
trace, even if it is manually set in the instrumentation.
This commit revisits the request observation setup and turns its context
into a regular `Observation.Context`. Tracing propagation should be
dealt with directly at the transport level by an underlying observation.
This is the case already for Spring Framework HTTP server observations.
As a result, the `PropagationWebGraphQlInterceptor` is deprecated with
no replacement and should not be used anymore.
Fixes gh-675
Support not only GraphQLObjectType, but any GraphQLFieldsContainer,
effectively also inspecting fields declared on an interface.
Add skipped types to report that includes any non-simple types that
have been skipped. Any type that is not a GraphQLFieldsContainer is
skipped, including unions. Types may also be skipped because of
insufficient Java object type information, e.g. controller method
declared to return Object or Mono<?>.
Do not report issues related to scalar and enum type fields, which
don't have any structure and don't need further checks.
See gh-662
For a completely generic SortStrategy we can't provide any concrete
support we know neither the input structure nor the Object structure.
At best, a nearly empty argument resolver, which is not any better
than providing your own custom argument resolver.
Hence, SortStrategy is now explicitly based on Spring Data's Sort,
which enables us to provide concrete support with a base class.
See gh-620
