Need an alternative integration strategy to signal FederatedTracingInstrumentation whether trace should be done for request

[Jon Christiansen]

We need another strategy for integration of the federated tracing to provide various frameworks (and consumers of them) more flexibility in implementing the short-circuiting path when the header is not present. This will make it so implementors are not forced to have their context implement HTTPRequestHeaders and provides much more flexibility with integrations of FederatedTracing and frameworks like DGS and others, that do not implement HTTPRequestHeaders in their execution context objects.

Today, without this capability, upon integrating FederatedTracingInstrumentation into base graphql libraries that are used by services throughout my company that are using other frameworks (ie: DGS), the execution context objects do not implement the HTTPRequestHeaders interface. This results in their services being forced into an "tracing enabled all the time" stance or disable federated tracing altogether - consuming teams do not have the appetite to always have that enabled for every request and would like the headers to be honored. Our team supporting federation want the tracing enabled in all services that participate in federation. With this change, we have many more options at our disposal for getting it working across many more codebases.