Add experimental updateTracerConfigurations for dynamically updateable on/off instrumentation

[jackshirazi]

This enables dynamic config - it's all that is needed at the experimental level. For the complete solution it would be a TracerProvider.updateTracerConfigurations() interface method addition.

A usage example is https://github.com/elastic/elastic-otel-java/blob/main/custom/src/main/java/co/elastic/otel/config/DynamicInstrumentation.java

Essentially, the configuration is set with an updatable ScopeConfigurator (see below fragment), then that can be updated at any time with eg GlobalOpenTelemetry.getTracerProvider().updateTracerConfigurations()

  public void customize(AutoConfigurationCustomizer autoConfiguration) {
    autoConfiguration.addTracerProviderCustomizer(
        (providerBuilder, properties) -> {
          providerBuilder.setTracerConfigurator(
              UpdatableConfigurator.INSTANCE);
          return providerBuilder;
        });
  }

  public static class UpdatableConfigurator implements ScopeConfigurator<TracerConfig> {
    public static final UpdatableConfigurator INSTANCE = new UpdatableConfigurator();
    private final ConcurrentMap<String, TracerConfig> map = new ConcurrentHashMap<>();

    private UpdatableConfigurator() {}

    @Override
    public TracerConfig apply(InstrumentationScopeInfo scopeInfo) {
      return map.getOrDefault(scopeInfo.getName(), TracerConfig.defaultConfig());
    }

    public void put(InstrumentationScopeInfo scope, TracerConfig tracerConfig) {
      map.put(scope.getName(), tracerConfig);
    }
  }

I haven't added implementations for DefaultTracerProvider and ExtendedDefaultTracerProvider nor tests, because I feel this is fine for the experimental stage, but those could be added easily

[codecov]

Codecov Report

Attention: Patch coverage is 13.33333% with 13 lines in your changes missing coverage. Please review.

Project coverage is 90.25%. Comparing base (7d74ada) to head (dde5f7e).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
...in/java/io/opentelemetry/sdk/OpenTelemetrySdk.java	0.00%	7 Missing ⚠️
.../io/opentelemetry/sdk/trace/SdkTracerProvider.java	0.00%	6 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #6899      +/-   ##
============================================
- Coverage     90.30%   90.25%   -0.06%     
- Complexity     6594     6595       +1     
============================================
  Files           729      729              
  Lines         19784    19799      +15     
  Branches       1945     1945              
============================================
+ Hits          17866    17869       +3     
- Misses         1325     1338      +13     
+ Partials        593      592       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests

[jack-berg]

Thanks for starting to think about this. I think we need to have an API that solves the dynamic config problem for generically, rather than focusing specifically on tracer config.

What do you think about something like this: jack-berg@f74db3e#diff-8a27a2383ac52aa80c19c1c9789bf6c91e2c336c702f9bb4943e5e8cce7d07e0R103-R129

Demonstrated in a test here: jack-berg@f74db3e#diff-cb1bd4f971c5bffe08539f05be0e05fe0750268975f448c45dcd78debd6775ecR257-R278

having a SdkTracerProvider.update(SdkTracerProvider target) method allows us to extend the method with additional update functionality as it makes sense. Could add similar method to SdkMeterProvider and SdkLoggerProvider, starting just with scope configuration, and slowly expanding to include other concepts like samplers, attribute limits, exporters, etc.

[jack-berg]

Per our conversation in yesterday's SIG about having scope config part of declarative configuration, I've opened this PR: open-telemetry/opentelemetry-configuration#140