Bump 2.16 branch to OTel 1.23 and SR reactive messaging 3.24

[brunobat]

No description provided.

[quarkus-bot]

/cc @radcortez (opentelemetry)

[gsmet]

What's the rationale for backporting this bump?

[brunobat]

It was asked by a user, but @ozangunalp has more details.

[ozangunalp]

I can't find the discussion right now. The reactive messaging 3.24.0 also includes the fix for #31003.

[gsmet]

OK, makes sense then if not too risky. Thanks for the clarification.

[ozangunalp]

Test failures seem to be related. I am looking at it.

[ozangunalp]

The Kafka record offset Otel attribute changed in the previous Reactive Messaging release.
I also backported that commit.

[quarkus-bot]

✔️ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

[gsmet]

I had a look at all the tests you had to adjust and this PR actually worries me a lot. Is it really safe to backport that to 2.16?

[radcortez]

These are related to two significant changes from OTel:

• Span name for http server spans should include http.method. open-telemetry/opentelemetry-specification#2998 (changed the span name to include the HTTP method).
• Rename all methods in all Getters to use the get*() naming scheme open-telemetry/opentelemetry-java-instrumentation#7619 (method renames in the OTel API)

The problematic piece is the method renames. They just renamed the methods, and there was no deprecation cycle. These could break user applications if they are using these APIs. My gut feeling is that the chance is small because these APIs are mostly for libraries integration, but we should be aware of this.

[gsmet]

@radcortez yeah so I knew about these changes, my problem is if they are safe enough to be backported to 2.16 given we are already late in the 2.16 cycle so people are expecting stability.

[radcortez]

Yes, I agree that these changes should not be expected in a patch release.

Even with the span name change, it would look weird to start seeing different span names in your tools. We could override their span name creator to keep the old behavior for this version. On the other hand, it would also look weird because this OTel version changes the name, and we are changing it again :)

Can we clarify what the user needs to ask for the backport?

[brunobat]

This started on a SM Reactive messaging backport request. Because OTel 1.23 is a dependency, it requires Otel backport due the mentioned changes, this was created.
If @ozangunalp is happy not to backport we can scrap this.

[ozangunalp]

I agree with the stability argument. No problem for me to scrap this PR.
In any case, I can't find the original user request.

[brunobat]

Dropping it.