Add setEnabledProtocols option to OTLP exporter builders

[jack-berg]

Fixes #7573

[otelbot]

⚠️ API changes detected — additional maintainer review required

@jack-berg @jkwatson

This PR modifies the public API surface area of the following module(s):

• opentelemetry-exporter-otlp
• opentelemetry-sdk-common

Please review the changes in docs/apidiffs/current_vs_latest/ carefully before approving.

[jack-berg]

I was happy to see a nearly identical API from armeria

[codecov]

Codecov Report

❌ Patch coverage is 94.20290% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 91.63%. Comparing base (c12e11b) to head (edafbee).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
...ry/exporter/sender/jdk/internal/JdkHttpSender.java	80.00%	0 Missing and 1 partial ⚠️
...orter/sender/okhttp/internal/OkHttpGrpcSender.java	87.50%	0 Missing and 1 partial ⚠️
...orter/sender/okhttp/internal/OkHttpHttpSender.java	90.00%	0 Missing and 1 partial ⚠️
...ntelemetry/sdk/common/export/HttpSenderConfig.java	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##               main    #8610   +/-   ##
=========================================
  Coverage     91.63%   91.63%           
- Complexity    10326    10350   +24     
=========================================
  Files          1013     1013           
  Lines         27295    27356   +61     
  Branches       3205     3217   +12     
=========================================
+ Hits          25011    25069   +58     
- Misses         1558     1559    +1     
- Partials        726      728    +2     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[opentelemetry-pr-dashboard]

Pull request dashboard status

Status: Waiting on @jack-berg to address or respond to review feedback.

Top-level feedback waiting on the author:

• Feedback 1

Please give each review feedback item a clear outcome: link to the commit that addresses it, explain why no change is needed, or ask a follow-up question.

[adhamahmad]

Hey @jack-berg, thanks for the detailed analysis.

I had one question about test coverage: is there a test that verifies the actual motivating scenario from #7573 — successfully reaching a real TLSv1/TLSv1.1-only server with enabledProtocols set and the JVM floor opened?

As written, enabledProtocols() only exercises TLS 1.2/1.3 against a TLS 1.2/1.3 server, which would still pass if setEnabledProtocols() were a no-op since that is already the default range.
I don't see a test covering the full "both gates open" scenario against a legacy server, which was the original bug report.

I ran into a related issue testing this in my PR: jdk.tls.disabledAlgorithms behavior is JVM-wide, and changing it at runtime can be problematic once TLS initialization has already happened. That made a legacy-server test order-dependent in practice.
If that is why this scenario was intentionally omitted, that makes sense as a stability tradeoff.

I just wanted to confirm whether that was the reasoning, or if I missed an existing test covering it.