feat: enable propagators using ENV vars

[jtmalinowski]

Which problem is this PR solving?

• Implements propagators part of General environment configuration #1675

Short description of the changes

• set global propagators using OTEL_PROPAGATORS environment variables

[codecov]

Codecov Report

Merging #1929 (d533c2a) into main (031b0f4) will increase coverage by 0.15%.
The diff coverage is 97.14%.

❗ Current head d533c2a differs from pull request most recent head e03dfaf. Consider uploading reports for the commit e03dfaf to get more accurate results

@@            Coverage Diff             @@
##             main    #1929      +/-   ##
==========================================
+ Coverage   92.59%   92.74%   +0.15%     
==========================================
  Files         137      137              
  Lines        4872     4904      +32     
  Branches     1005     1012       +7     
==========================================
+ Hits         4511     4548      +37     
+ Misses        361      356       -5     

Impacted Files	Coverage Δ
...s/opentelemetry-tracing/src/BasicTracerProvider.ts	96.61% <95.65%> (+18.23%)	⬆️
...elemetry-core/src/context/propagation/composite.ts	100.00% <100.00%> (ø)
...ckages/opentelemetry-core/src/utils/environment.ts	100.00% <100.00%> (ø)
...kages/opentelemetry-node/src/NodeTracerProvider.ts	100.00% <100.00%> (ø)
...emetry-core/src/platform/node/RandomIdGenerator.ts	87.50% <0.00%> (-6.25%)	⬇️

[jtmalinowski]

@dyladan @obecny @vmarchaud now that Jaeger is in core we can start relying on it and thinking about merging this. I'm trying to gather early feedback, because I remember last time there were issues raised about API of registering/consuming propagators.

Here's my thoughts. Defaults are set per spec (tracecontext, baggage) and programatically setting propagator in BasicTracerProvider stays the same. b3, b3multi, jaeger work out of the box in NodeTracerProvider.

For xray and ottrace and any other 3rd party propagators I see 2 ways:

• vendor subclasses WebTracerProvider or NodeTracerProvider and overrides protected BasicTracerProvider#_getPropagator
• vendor exports a function such as registerXrayPropagator() which uses BasicTracerProvider.registerPropagator

We could argue that if vendor requires code changes to register a propagator then why bother with ENV at all? I think that if we have a concept of OTEL_PROPAGATORS then all propagators be it 1st or 3rd party should conform to the interface. Example use case could be devops' ability to change propagation without changing code.

I'm unsure how to handle xray and ottrace when they are not registered. Should we include a dedicated warning for them? (they are listed as known propagators in the spec)

[dyladan]

Looks good to me thanks

[dyladan]

These have nothing to do with propagator

[johnbley]

LGTM

[vmarchaud]

@jtmalinowski Thanks for taking the time to finish the PR !

[jdmarshall]

I don't see any way to register a propagator at present.

[legendecas]

@jdmarshall would you mind opening an issue to elaborate on your problem instead? thank you!