Split out okhttp4 sender

[jack-berg]

Related to #8001. Related to #8046.

Opening as a draft to get the conversation started.

Currently, opentelemetry-exporter-sender-okhttp supports okhttp 4.x and 5.x. We verify this by running our thorough test suite with both versions. This fact is hard to discover. We could advertise it better in our docs. But this pattern probably isn't sustainable and should expect breaking changes in future major version bumps.

This PR breaks out a separate opentelemetry-exporter-sender-okhttp4 sender for compatibility with okhttp 4.x.

Some points to discuss:

• opentelemetry-exporter-sender-okhttp is for okhttp 5.x We could do opentelemetry-exporter-sender-okhttp5, but that's artifact churn which isn't strictly necessary. Of course if v6 comes out, we'd have to publish opentelemetry-exporter-sender-okhttp6. And so at that point opentelemetry-exporter-sender-okhttp would look like the outlier. So maybe opentelemetry-exporter-sender-okhttp5 is worth considering.
• We need add a statement to VERSIONING.md about how long we'll support different okhttp major versions. Something simple would be to support major versions as long as okhttp support them. Or we could be more aggressive and say we support N-1 major versions, where N is the latest major version. So when v6 comes out, we drop support for v4.
• We should think about code maintenance. Currently, I just did a straight copy / paste of the opentelemetry-exporter-sender-okhttp code. This makes it easy for the code to diverge. We could also build gradle tooling to automatically make a copy in a generated source set excluded from gradle. Or similarly, we could build gradle tooling which throws an error if the two copies are out of sync. If breaking changes occur in the next major version, the sender code won't be able to be an exact copy, but we can cross that bridge later.
• Version management and rennovate needs some thought. For simplicity, I currently just pulled okhttp from dependencyMangement. This leaves version constants scattered around the codebase. Maybe it would be enough to keep the dependencyManagement pinned to the latest, and force resolve to okhttp 4.x only in the select few places that need it.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.00%. Comparing base (cfe93d0) to head (77a118b).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #8086      +/-   ##
============================================
- Coverage     90.21%   90.00%   -0.22%     
+ Complexity     7605     7588      -17     
============================================
  Files           841      841              
  Lines         22923    22923              
  Branches       2291     2291              
============================================
- Hits          20681    20631      -50     
- Misses         1525     1562      +37     
- Partials        717      730      +13     

☔ View full report in Codecov by Sentry.
📢 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.