Permit to pass SslParameters to ExporterBuilders for fine grain TLS configuration

[NilsRenaud]

Problem

Post quantum resistant key exchange for TLS RFC is quite stable, enough for Java to implement it in JDK 27.
So when running the JDK OpenTelemetry exporter on java 27, it'll use a post-quantum-resistant algorithm as primary choice (X25519MLKEM768), and this can be defined at the entire JVM level with jdk.tls.namedGroups property.

The issue arise when we want to enforce OTLP to use only PQ-resistant algorithm (by setting jdk.tls.namedGroups=X25519MLKEM768 for example) while needing to call external services that does not offer yet a PQ-resistant key exchange algorithm.
Since the property affects the whole JVM other HttpClients will be impacted.

Proposed solution

Since HttpClient builder accepts javax.net.ssl.SSLParameters, I'd like to be able to pass an instance of these parameters alongside the SslContext in xxxExporterBuilder (such as OtlpHttpLogRecordExporterBuilder).
This way we could easily low level parameters of future TLS handshakes.

Alternatives/Workaround

Since one can currently pass an SslContext, it's possible to create a custom SslContext that will set SslParameters to the SslEngines it produces. But that's about 150 lines of boilerplate code...

Additional context

PostQuantum resistance is a hot topic right now, lots of countries have set deadlines for critical software to become PQ-resistant.

_{Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[cfcromn]

Hi maintainers, I’m interested in investigating this feature request.

From the issue description, the goal seems to be allowing per-exporter TLS configuration by passing SSLParameters to OTLP HTTP exporter builders, instead of relying on JVM-wide properties such as jdk.tls.namedGroups.

Before attempting an implementation, I’d like to confirm the preferred API direction:

1. Should this be exposed as a new setSslParameters(SSLParameters sslParameters) method on the OTLP HTTP exporter builders?
2. Should it apply consistently to trace, metric, and log record HTTP exporters?
3. Should the behavior be limited to the JDK HttpClient sender, or should OkHttp-based senders also support it where possible?
4. When both sslContext(...) and sslParameters(...) are configured, should the builder pass both to the underlying HTTP client?
5. Since SSLParameters is mutable, should the builder defensively copy it when it is provided?

If this direction sounds reasonable, I’d be happy to prepare a focused PR with tests covering propagation of the configured SSLParameters.