Initial composite/global Propagators update for OTEP 66.

[carlosalberto]

This is an initial PR focusing on updating the Propagators API, and is meant to be get initial feedback, rather than getting merged right away. This is because related PRs are still not merged, which hopefully will change soon ;)

Overall:

1. Composite Propagator concept: Even though in OTEP 66 this part is rather defined as a function taking a list of propagators, I think it makes sense to try to go with a composite Propagator concept.
2. (Optional) Global Propagators. This has TraceContext/CorrelationContext as default global propagators, as some language implementations already do this.

[carlosalberto]

@open-telemetry/specs-approvers please take a look at this one too ;)

[dyladan]

Do we want one global propagator (which may be composite), or do we want to add the propagator to the TracerProvider? Reason being that if you have multiple apps in a single runtime, each of which has its own tracer provider, you may want to use different propagation formats between apps.

[carlosalberto]

To me doing that sounds like an overkill for now - in practice, it looks like most people want a single place/component to do the entire injection/extraction.

We could add in the future an additional Propagator component to items such as TracerProvider and similar components (defaulting to null) in case users want to (optionally) override the global one, though 😃

[dyladan]

How should we be calling the propagator?

1. api.propagator.extract(...)
2. tracer.extract(...)
3. tracer_provider.extract(...)

[carlosalberto]

You should be using 1) as this will be the 'default' thing - we might (but we might not) add 3) as a custom, override thing, in which case we could call that one as well.

The second option is due to be removed ;)

[dyladan]

Are we going to specify whether inject mutates the carrier or returns a new one?

[carlosalberto]

So currently the carrier that is passed is in turn passed to the Setter instance, which decides what to do with it along with the keys/values. In practice (99% of the time?) the carrier is indeed mutated, but not 'enforced'.

[dyladan]

I was going to mark this as resolved, but for some reason don't have the button available like in the spec repo. Are permissions different here?

[yurishkuro]

The Carrier APIs should be defined earlier in the doc. They are generally mutable by definition, although I could see how this could irk some FP-oriented people. It is rather difficult to make individual pieces immutable and composable, because the Carrier API fundamentally implies some transformation that is unknown to the propagator, like writing every key-value pair as HTTP header is a specific implementation of HTTPRequest.

[yurishkuro]

(well, it's actually not THAT difficult, using some pipeline like propagators.map(_.stateAsMap(context)).flatMap(carrier.accumulate),
but it's rather inefficient).

[arminru]

@dyladan You need to be the author who opened the PR or have write permissions to the repo (i.e., be in spec-approvers) to resolve conversations.

[yurishkuro]

I do not follow anything in the preceding Fields section. It seems very vague and random. And certainly does not belong specifically under the HTTP format.

[yurishkuro]

Why do we need to separate carrier and setter?

[carlosalberto]

Hey @yurishkuro thanks for the feedback. I've fixed the issues that are strictly related to this PR, and have created #453 to keep track the changes api-propagators.md overall needs (assigning it to myself).

Please re-review and let me know ;)