feat(sdk-trace)!: remove ability to have BasicTracerProvider instantiate exporters

[pichlermarc]

Which problem is this PR solving?

This is apparently a feature we offer - overriding a static property to register exporters, which can then be instantiated via env vars. And also overriding methods that facilitate the creation of exporter via env vars. It ends up in both Web and Node.js tracing packages.

I don't recall the context of why this was added but I know it was used in NodeSDK but that offers a better approach now that does not rely on that behavior anymore. I reckon few of our users even know that this feature exists.

This PR proposes removing this feature. If this feature is needed, we can just provide a function that does this (or they can implement it themselves, it's trivial to do), and require the person to pass it the result to the constructor as spanProcessors, which should be much cleaner.

I'm not sure yet what to do with propagators which offer a similar functionality, but I'm confident that we can come up with a simpler to use/maintain/understand solution for that.

Type of change

• Breaking change (fix or feature that would cause existing functionality to not work as expected)

How Has This Been Tested?

• Unit tests

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.52%. Comparing base (47212bb) to head (2eae41a).
Report is 1 commits behind head on next.

Additional details and impacted files

@@            Coverage Diff             @@
##             next    #5239      +/-   ##
==========================================
- Coverage   94.56%   94.52%   -0.04%     
==========================================
  Files         316      316              
  Lines        8037     8020      -17     
  Branches     1628     1622       -6     
==========================================
- Hits         7600     7581      -19     
- Misses        437      439       +2     

Files with missing lines	Coverage Δ
...elemetry-sdk-trace-base/src/BasicTracerProvider.ts	95.55% <ø> (-0.71%)	⬇️

... and 1 file with indirect coverage changes

[david-luna]

so IIUC it means now BasicTraceProvider wont' look up to env to resolve the exporter and it is mandatory to pass it into the constructor right?

This means NodeSDK or any other component creating the provider is responsible to resolve the exporter from env if applies right?

[pichlermarc]

so IIUC it means now BasicTraceProvider wont' look up to env to resolve the exporter and it is mandatory to pass it into the constructor right?

This means NodeSDK or any other component creating the provider is responsible to resolve the exporter from env if applies right?

Yep - that's the solution I'd propose. 🙂

This PR is just a proposal, so we don't have to do it, but I feel like this is a cleaner approach as we'd eliminate an additional (confusing) way to accomplish the same thing.

Neither the LoggerProvider nor MeterProvider have equivalent functionality and I'm not aware of any requests that I remember that asked for adding it. 🤔 Removing it also has the bonus of aligning functionality between the three signals. I'd like to align the three signals as much as possible to give a more consistent experience to end-users.