Fix OkHttp client mTLS when using the platform default trust store

[Debashismitra01]

Summary

This PR fixes an inconsistency between the OkHttp and JDK OTLP HTTP senders when client mTLS is configured without custom trusted certificates.

Previously, when only setClientTls(...) (or the equivalent autoconfigure properties) was configured, TlsConfigHelper correctly created an SSLContext containing the client KeyManager, but the OkHttp sender skipped installing the custom SSLSocketFactory because no explicit X509TrustManager was provided. As a result, OkHttp fell back to the platform default SSLSocketFactory, causing the configured client certificate to be silently omitted during the TLS handshake.

This change resolves the platform default X509TrustManager when no custom trust manager is configured and uses it when installing the custom SSLSocketFactory, making the OkHttp sender behave consistently with the JDK sender.

Changes

• Add a helper for resolving the platform default X509TrustManager.
• Use the platform default trust manager when configuring the OkHttp HTTP sender if no custom trust manager is supplied.
• Add a regression test covering client mTLS without custom trusted certificates against an mTLS-required endpoint.

Fixes #8562

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: Debashismitra01 / name: Debashismitra01 (64d015e, c0a6159, d6866b5, ea96f60, ec843fa)

[codecov]

Codecov Report

❌ Patch coverage is 59.09091% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 91.52%. Comparing base (4d974ba) to head (09b53c2).

Files with missing lines	Patch %	Lines
...va/io/opentelemetry/exporter/internal/TlsUtil.java	37.50%	3 Missing and 2 partials ⚠️
...entelemetry/exporter/internal/TlsConfigHelper.java	66.66%	2 Missing ⚠️
...orter/sender/okhttp/internal/OkHttpHttpSender.java	75.00%	2 Missing ⚠️

❌ Your patch check has failed because the patch coverage (59.09%) is below the target coverage (80.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #8565      +/-   ##
============================================
- Coverage     91.55%   91.52%   -0.03%     
- Complexity    10262    10264       +2     
============================================
  Files          1013     1013              
  Lines         27102    27121      +19     
  Branches       3182     3184       +2     
============================================
+ Hits          24812    24822      +10     
- Misses         1565     1572       +7     
- Partials        725      727       +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.

[Debashismitra01]

Hi! I ran into an issue with the patch coverage check. The remaining uncovered lines are primarily defensive exception paths introduced by the new default trust manager resolution (e.g. TlsUtil.defaultTrustManager() failure handling). These paths are difficult to exercise without introducing static mocking of JDK/Mockito internals.

I considered refactoring the implementation to reduce the uncovered branches, but that would either reintroduce the original bug or require resolving the default trust manager multiple times, which I'd prefer to avoid. Before I proceed further, could you advise on the preferred direction?

Should I add tests using static mocking for these exception paths?
Or would you prefer a different implementation that keeps the fix simpler while preserving the intended behavior?

I'd appreciate your guidance on which approach best fits the project's expectations.