DataFetcher observations have incorrect hierarchy

[bclozel]

When recording data fetcher observations, the GraphQlObservationInstrumentation organizes the parent/child relationship between 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 results in traces where data fetching operations are set with incorrect parent/child relationships. We should instead use the ExecutionStepInfo to ensure that the correct observation information is used.

Thanks @tkmax83 for providing a sample application.

[bclozel]

Reopening as the fix is incomplete.
For DataFetcher observations, we cannot use the global GraphQLContext as it shared for the entire GraphQL request (and no thread safe). The fix above relies on an externally maintained map tracking observations and their execution step info. This fix is incomplete, as the DataFetcher observation will not be set as current anywhere, and DataFetcher implementations will not see it as current in the ThreadLocal or reactive context.

In this case, we should probably use the graphql.schema.DataFetchingEnvironment#getLocalContext to provide context values that are local to field fetching operations. For this fix to be complete, we need the ContextDataFetcherDecorator to capture values from both the global and local GraphQLContext, see #688.

[bclozel]

Reopening as the instrumentation breaks the data fetchers that return CompletableFuture. See #692.