Update open telemetry dependencies and switch to using the built in JDK http client for reporting traces

[SamBarker]

This PR removes the dependency on OkHttp and thus Kotlin in a fully backwards compatible fashion. It does this by replacing the opentelemetry-exporter-sender-okhttp (which is the OpenTelemetry default) with two separate senders. One for each transport.

• opentelemetry-exporter-sender-jdk enables sending traces using http/protobuf which is the lowest common denominator option, as its the only method required by the OpenTelemetry specifications.
• opentelemetry-exporter-sender-grpc-managed-channel enables support for sending traces using grpc and thus feature parity with the OkHttp sender.

In doing so it has brought in a newer version of the SemanticConventions library which has deprecated several of the used conventions. I have added the new fields where appropriate and suppressed the deprecation warnings as we need to propagate the changes to users.

[SamBarker]

With fresh eyes I realised there was a way to restore GRPC support (however that does require OpenTelemetry 1.34.0+). By adding dependencies on opentelemetry-exporter-sender-grpc-managed-channel and grpc-netty-shaded we can maintain GRPC support and remove the Kotlin dependency.

The build is now failing due to deprecations in the SemanticAttributes some of them are simple renames however others involve changing the value e.g. SemanticAttributes.HTTP_URL becomes SemanticAttributes.URL_FULL which means its not a backwards compatible change.

Obviously I'm happy to push up the simple renames however I'm looking for input from the maintainers for what to do about the non backwards compatible changes. The build fails due to using the deprecated properties but changing them breaks compatibility.

[ppatierno]

With fresh eyes I realised there was a way to restore GRPC support (however that does require OpenTelemetry 1.34.0+). By adding dependencies on opentelemetry-exporter-sender-grpc-managed-channel and grpc-netty-shaded we can maintain GRPC support and remove the Kotlin dependency.

Is it a documented way or an hack? Also I think that the deprecation issues makes things more complicated.

[SamBarker]

I found it through the pull requests but they are listed in the docs.

The realisation I had was both could be on the classpath and autoconfigure will work out which one it actually needs based on the configuration.

[SamBarker]

Oh and as I forgot to mention it earlier the need for 1.34.0 rather than 1.28.0 where the sender was introduced was this bug fix

[ppatierno]

@SamBarker I had another pass but I see some comments were not addressed.

[ppatierno]

@SamBarker I left just a nit and there are conflicts to fix before approving the PR. Thanks!

[SamBarker]

@ppatierno @scholzj I believe everything has been addressed and the PR checks are happy modulo a PR approval 😉

[ppatierno]

LGTM. Thanks for the PR!

[ppatierno]

I tested (again) this PR and it seems to work fine, even switching between using grpc (default) to http/protobuf.
@SamBarker could you fix the conflicts please? We want to validate that with the same versions (as you set on strimzi/strimzi-kafka-operator#9758), OpenTelemetry works in the operator as well (KafkaConnect and KafkaMirrorMaker). After this check, I think we can move forward and merge both.

[SamBarker]

We want to validate that with the same versions (as you set on strimzi/strimzi-kafka-operator#9758), OpenTelemetry works in the operator as well (KafkaConnect and KafkaMirrorMaker). After this check, I think we can move forward and merge both.

I'm not clear what you want me to do, if anything, for that. The versions are the same across both this and the operator PR and the operator regression suite passed. Though that ran with the version of the bridge with out these changes.

[ppatierno]

I'm not clear what you want me to do, if anything, for that. The versions are the same across both this and the operator PR and the operator regression suite passed. Though that ran with the version of the bridge with out these changes.

Maybe it was a misleading comment but I didn't want nothing to do from you :-D
I meant to wait for the PR on the operator to work fine before merging this one, in order to validate that same OTel versions were working fine on both (operator and bridge).