feat: tracers provided by the API become useable when provider registered

[dyladan]

This is important to fix the load order issue as it relates to plugin setup. Currently, plugins can't be set up until after the tracer provider is created, and creating the tracer provider starts the resource detectors. If a resource detector like GCP uses a module that needs to be instrumented, the plugin may not be able to instrument it if it is loaded after the resource detectors run.

After this PR, plugins can be set up before the tracer provider. When they are constructed, they will acquire Proxy Tracers from the API. Then, when the tracer provider is registered, those proxy tracers become fully useable without the plugin having to acquire a new tracer.

[mwear]

Looks great!

[obecny]

I'm missing the whole picture, how the new proxy classes should be used outside of api. I checked the draft for new base plugin and they are not used there, is this still in progress ? If exporting them is intentional where are they going to be used yet and how? thx

[dyladan]

I'm missing the whole picture, how the new proxy classes should be used outside of api.

The basic idea is that if a library has built-in instrumentation, we will not have as much control over load order. We might have the case where a library is required and it calls getTracer before the SDK is initialized. In that case, the tracer the library has acquired will become useable when the SDK is registered without that library having to call getTracer again.

I checked the draft for new base plugin and they are not used there, is this still in progress ? If exporting them is intentional where are they going to be used yet and how? thx

The API is used the exact same way by users and plugins with no change. The only difference is that if you call getTracer before the SDK is initialized, the API will return a ProxyTracer which proxies to a noop tracer instead of a noop tracer directly. The proxy classes should probably not be exported. I will remove those exports.

[obecny]

@dyladan it could be merged once you resolve the conflicts

[dyladan]

Build still needs to be fixed

[codecov]

Codecov Report

Merging #1448 into master will decrease coverage by 0.05%.
The diff coverage is 88.09%.

@@            Coverage Diff             @@
##           master    #1448      +/-   ##
==========================================
- Coverage   93.91%   93.85%   -0.06%     
==========================================
  Files         151      153       +2     
  Lines        4615     4656      +41     
  Branches      953      960       +7     
==========================================
+ Hits         4334     4370      +36     
- Misses        281      286       +5     

Impacted Files	Coverage Δ
...ackages/opentelemetry-api/src/trace/ProxyTracer.ts	82.60% <82.60%> (ø)
...opentelemetry-api/src/trace/ProxyTracerProvider.ts	92.85% <92.85%> (ø)
packages/opentelemetry-api/src/api/trace.ts	92.30% <100.00%> (+1.39%)	⬆️