Support disabling trace header propagation for same origin requests in the XMLHttpRequest instrumentation

[eastenluis]

Is your feature request related to a problem? Please describe.

Currently, the XMLHttpRequest instrumentation always propagates the trace headers for same-origin requests. While it is useful to link the client and server spans, it also creates some challenges to process traces.

One of the challenges is the increasing amount of missing root spans. This is most likely due to clients failing to send the trace data to our collector, which can be caused by many factors we cannot control (e.g. browser blocking telemetry requests, bad client network, user tabs/browsers ending before the telemetry requests were sent). This makes it difficult to investigate other potential issues that can cause similar problems (e.g. other services failed to send the traces), and harder to decide the proper sampling.

Another challenge is that the request spans can sometimes be unexpectedly long (e.g. an hour) while the server spans are very short (e.g. a few hundred milliseconds). It's likely due to browser issues that we also cannot control (e.g. the client tab idles after the response is received but before the response is fully loaded). The long duration spans lead to longer processing time for the whole trace at the collector.

While we want to investigate the actual reasons, linking the web client and server traces doesn't provide enough values at the moment. The instrumentation always injects the header, so we currently write custom codes to override the package methods to avoid setting the headers. We would like a solution to optionally stop the trace propagation at the instrumentation package level so we don't write workarounds.

Describe the solution you'd like

In the XMLHttpRequest instrumentation, add an option to stop propagating trace headers for the same origin requests. For example:

    new XMLHttpRequestInstrumentation({
        disableSameOriginRequestTraceHeaderPropagation: true,   // `false` by default for backward compatibility
    }),

We may not need an option for CORS requests as we have to specify them for propagation.

Describe alternatives you've considered

We can alternatively have a blacklist option to stop propagating requests that match the patterns. But I think that could lead to over-complex design to maintain for the current usages.

Additional context