Possibility to re-initialize OpenTelemetry runtime

Is your feature request related to a problem? Please describe.
I would like to reconfigure OpenTelemetry during runtime without restarting my process. However, the GlobalOpenTelemetry API is designed to be immutable for the whole lifespan of the application.

https://github.com/open-telemetry/opentelemetry-java/blob/cb44b2b18c474f80478184ff1665bc3fa5d2ced3/api/all/src/main/java/io/opentelemetry/api/GlobalOpenTelemetry.java#L106-L113

Describe the solution you'd like
The GlobalOpenTelemetry class could allow changing the registered OpenTelemetry object, and could provide a reactive interface:

I can register a new OpenTelemetry object every time a user logs in for example:

UserSession userSession = myUserService.login(...);
MyCredentials creds = myService.getOtlpCredentials(userSession);
OpenTelemetrySdk.builder()
  .setTracerProvider(
    SdkTracerProvider.builder()
      .addSpanProcessor(
        OtlpGrpcSpanExporter.builder()
          .addHeader("Authorization", creds.mySecretAuthorizationHeader)
          .build()
      )
      .setResource(resource)
      .build();
  )
  .buildAndRegisterGlobal();

And my services can create their OpenTelemetry derived fields reactively:

class MyService {
  private Tracer myTracer;
  private OpenTelemetryChangedListener listener = new OpenTelemetryChangedListener() {
    public void openTelemetryChanged(OpenTelemetry openTelemetry) {
      myTracer = openTelemetry.getTracer("MyService");
    }
  };

  public void init() {
    GlobalOpenTelemetry.registerListener(listener);
  }
  public void shutdown() {
    GlobalOpenTelemetry.unregisterListener(listener);
  }
}

Describe alternatives you've considered
AFAIK the only way to change the registered OpenTelemetry object on GlobalOpenTelemetry is to restart the application.

Alternatively, I could prevent using the GlobalOpenTelemetry API, as well as the Java Instrumentation library, but that would defeat their purpose, wouldn't it?

Additional context
I stumbled upon two related use-cases, but please let me know, if there would be better ways to do things:

1. Client-side instrumentation, where my Otel backend's basic auth/OIDC credentials are scoped to a user session. I don't want to hardcode the basic auth/OIDC credentials into my distributed application, instead, I would like to securely pass them to my clients, when users have successfully logged in to my service. So on each login, I would like to register a new OpenTelemetry object for GlobalOpenTelemetry, and on each logout, I would like to unregister it.
2. Server-side instrumentation, with legacy long-running applications. Since there is no rolling update or load-balancing available for my legacy service, I would like to be able to change certain OpenTelemetry parameters (such as sampling rate or the list of sampled methods) without restarting my service, in order to prevent downtimes for my users. In a perfect world, the Java Instrumentation library could watch for changes in my configuration file, and would register a new OpenTelemetry object on GlobalOpenTelemetry, when any changes to my configuration occur (which is not possible with the current GlobalOpenTelemetry design).

Start with api/all/src/main/java/io/opentelemetry/api/GlobalOpenTelemetry.java, especially the linked registration logic, then review how the Java Instrumentation configuration and SDK registration interact. Done means defining and agreeing on a safe runtime reconfiguration and listener lifecycle design that addresses the stated client- and server-side use cases.