HttpExporterBuider.resolveHttpSenderProvider uses a static class loader, not a configurable one, or AutoConfiguredOpenTelemetrySdkBuilder's

[pbalint]

Describe the bug
HttpExporterBuider.resolveHttpSenderProvider uses its own class loader for finding HttpSenderProvider-implementations:

opentelemetry-java/exporters/common/src/main/java/io/opentelemetry/exporter/internal/http/HttpExporterBuilder.java

Line 253 in 77bb439

ServiceLoader.load(HttpSenderProvider.class, HttpExporterBuilder.class.getClassLoader())) {

This does not work in an OSGi-environment, because simple class loaders like these are only able to inspect their own jars.

Ideally, there should be a configurable SPI to be used for class loading, like the one used by AutoConfiguredOpenTelemetrySdkBuilder:

opentelemetry-java/sdk-extensions/autoconfigure/src/main/java/io/opentelemetry/sdk/autoconfigure/AutoConfiguredOpenTelemetrySdkBuilder.java

Lines 400 to 405 in 66cf1b6

	public AutoConfiguredOpenTelemetrySdkBuilder setServiceClassLoader(
	ClassLoader serviceClassLoader) {
	requireNonNull(serviceClassLoader, "serviceClassLoader");
	this.spiHelper = SpiHelper.create(serviceClassLoader);
	return this;
	}

Steps to reproduce
Try autoconfiguring OTEL in an OSGi-environment like this:
OTEL_TRACES_EXPORTER: otlp
OTEL_METRICS_EXPORTER: none
OTEL_LOGS_EXPORTER: none
OTEL_EXPORTER_OTLP_TRACES_PROTOCOL: http/protobuf

What did you expect to see?
OTEL is able to find the implementation coming from opentelemetry-exporter-sender-okhttp

What did you see instead?
The exception:
No HttpSenderProvider found on classpath. Please add dependency on opentelemetry-exporter-sender-okhttp or opentelemetry-exporter-sender-jdk

What version and what artifacts are you using?
Artifacts: Please see the excerpt below
Version: 1.34.1
How did you reference these artifacts? (excerpt from your build.gradle, pom.xml, etc)
io.opentelemetry:opentelemetry-sdk-common:jar:1.34.1true
io.opentelemetry:opentelemetry-sdk-trace:jar:1.34.1true
io.opentelemetry:opentelemetry-sdk-metrics:jar:1.34.1true
io.opentelemetry:opentelemetry-semconv:jar:1.30.1-alphatrue
io.opentelemetry:opentelemetry-exporter-otlp:jar:1.34.1true
io.opentelemetry:opentelemetry-exporter-sender-okhttp:jar:1.34.1true
io.opentelemetry:opentelemetry-exporter-logging-otlp:jar:1.34.1true
io.opentelemetry:opentelemetry-exporter-otlp-common:jar:1.34.1true
io.opentelemetry:opentelemetry-sdk-extension-autoconfigure:jar:1.34.1true
io.opentelemetry:opentelemetry-api-events:jar:1.34.1-alphatrue
io.opentelemetry:opentelemetry-sdk-extension-incubator:jar:1.34.1-alphatrue
io.opentelemetry:opentelemetry-sdk-testing:jar:1.34.1true

Environment
Compiler: N/A
OS: Windows 10, Correttor 17
Runtime (if different from JDK above): (e.g., "Oracle JRE 8u251")
OS (if different from OS compiled on): (e.g., "Windows Server 2019")

Additional context

[jack-berg]

Any ideas on how you would specify the alternative class loader?

I wonder why you haven't encountered this issue for the ContextStorageProvider SPI, which uses a statically defined class loader as well:

opentelemetry-java/context/src/main/java/io/opentelemetry/context/LazyStorage.java

Line 107 in f24acbd

for (ContextStorageProvider provider : ServiceLoader.load(ContextStorageProvider.class)) {

[pbalint]

I've fixed the link to AutoConfiguredOpenTelemetrySdkBuilder.java in the opening comment...

As for the how exactly could this be done, it would be the easiest to put the classloader setter (e.g. setClassLoader()) in a prominent place, like GlobalOpenTelemetry, or even into the OpenTelemetry interface, mandating support for it.