Feature Proposal: separateTraces option for XHR/Fetch instrumentations

[Abinet18]

Propose adding an optional separateTraces configuration flag to XMLHttpRequestInstrumentation and FetchInstrumentation that allows HTTP request spans to start a new root trace instead of inheriting the currently active span's trace context.

Use Case
In browser instrumentation, HTTP requests made inside event handlers (e.g., a button click) are automatically parented to the active interaction span. This is the correct behavior in most cases, but there are legitimate scenarios where it is undesirable:

Independent background operations — A fetch triggered by a user action may logically represent a separate concern (e.g., analytics ping, lazy data load, prefetch) that should not be grouped under the interaction trace.
Different observability domains — The backend service receiving the request may be owned by a different team or system, and cross-trace correlation is not desired or not supported.
Granular trace analysis — Consumers of telemetry may want to query and analyze network request performance independently from interaction traces, without filtering through parent-child relationships.
Trace cardinality control — Some backends charge or limit based on trace volume; being able to separate interaction and network traces gives operators finer control.

Proposed API

new XMLHttpRequestInstrumentation({ separateTraces: true })
new FetchInstrumentation({ separateTraces: true })

When separateTraces: true:

Each HTTP request span is created under ROOT_CONTEXT, giving it a new, independent traceId
A reference to the originating span can optionally be preserved via span links or attributes