Propagation Context Experiment Draft

[AbhiPrasad]

ref #8352

This draft PR represents me playing around with the API of a propagation context (aka distributed tracing context).

To make tracing without performance work, we are required to always have some kind of storage mechanism for distributed tracing context. This propagation context right now is supplemented by the existence of a transaction, which exists as the vehicle to carry this information.

With TwP, we are looking to introduce a source of truth that carries this trace information, that then everything will read from. This source of truth lives on the scope, as it is expected to change with incoming requests (node) or meta tags (browser) changing the trace.

This PR will be closed with the actual PR afterwards, but just wanted a place I can look at my ideas in the time being.

[AbhiPrasad]

Some things to think about

1. Do we refactor out transaction.getDynamicSamplingContext and replace with a common parent method? We need a way to generate dsc (also lazily) from just the client options.

My initial idea is to put a DSC generating method on the hub, which can use both the client/scope to do this logic. The transaction can reference this method accordingly then.

2. Should the scope expose explicit setters/getters or just HOC methods that return transforms of the propagation context? For example instead of getPropagationContext, you would call getTraceContextorgetDsc`. I'm shying away from multiple methods on the scope because it's bundle size inefficient.

3. Scope cloning/updating - what is the behaviour we want. In my eyes: Scope.clone should inherit the current propagation context. Scope.update should also update it so you can use initialScope to set your own trace id (might be useful in some circumstances idk - maybe a little too powerful though)