Prior to this commit, the `GraphQlObservationInstrumentation` would
instrument the following operations:
* GraphQL requests
* GraphQL data fetching operations
In the case of batch loading operations, the instrumentation would
consider each load call as a separate data fetching operation. This
would significantly clutter recorded traces and would make it look like
"N+1 problems" would still be present.
This commit adds a new "graphql.dataloader" observation for such
operations and avoids recording data fetching observations when
`SelfDescribingDataFetcher` declare that they call batch loading
operations.
Closes gh-1034
Prior to this commit, the `DefaultExecutionRequestObservationConvention`
would only produce "INTERNAL_ERROR" outcomes if the response is null or
if an unresolved exception remains.
The `ExceptionResolversExceptionHandler` will catch all unresolved
exceptions and add them to the errors map with the
`ErorType.INTERNAL_ERROR` error type. This means that the
"INTERNAL_ERROR" outcome is never used.
This commit ensures that this outcome is also used if at least one
resolved error is of `ErorType.INTERNAL_ERROR`.
Fixes gh-1058
Prior to this commit, GraphQL Request Observations would not record
errors as Observation errors, because with GraphQL errors can partially
affect the response and there can be multiple. Instead, an invalid
request (for example) would lead to a `"graphql.outcome", "REQUEST_ERROR"`
low cardinality KeyValue. In this case, developers would not know what
type of error occured nor if there were multiple.
This commit records all errors listed in the GraphQL as
Observation.Event on the request Observation. Such events are usually
handled by the tracing handler and are recorded as span annotations for
traces. Other `ObservationHandler` annotations can leverage events in a
different fashion.
Closes gh-859
