Add messaging wrappers to support lightweight manual instrumentation

[Cirilla-zmh]

Description:

This PR introduces a complete implementation of a generic messaging process wrapper API, designed to facilitate the creation of process spans and the propagation of trace context in a standardized and lightweight manner. It builds upon the initial draft presented in PR #1803, which provides additional context for this work.

Key features and contributions include:

• Generic Process Wrapper API: A flexible and reusable API that supports the creation of process spans and ensures trace context propagation across different libraries and frameworks.
• Library Implementations:
  • Added support for kafka-clients.
  • Added support for aliyun-mns-sdk (Alibaba Cloud Simple Message Queue).

Existing Issue(s):

• https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/13340
• https://github.com/open-telemetry/opentelemetry-specification/issues/4426

Testing:

• [x] Base API integration tests.
• [x] Integration tests for kafka-clients.
• [x] Integration tests for aliyun-mns-sdk (pending for building mocked server).

Documentation:

For detailed usage instructions and API documentation, please refer to the updated README.md

[linux-foundation-easycla[bot]]

The committers listed above are authorized under a signed CLA.

• :white_check_mark: login: Cirilla-zmh / name: Minghui Zhang (b6ed6c692ea3f8f98c2d5ab03882606fb4da5a42, 568619906fbc559dc1ad2c395705052ebf8a6148, 8a6dc8cc4067bfff7a925e2be9cebdaf3c49757e, 7ae27319bf83909e2d081b93b2a841b195a4c6e1, 8ef16f8e044e4a15f5b84bd518d98c52b30470be, eddb143439a2224c03d74831304d1ac83ac693c6, 6f3587be0abfe4553e3f240d8d88f02c93f44106, e588d1e0ab0486c95673322880a23d79a4429bc6, 77e30018f686f1a139cb4e875c1941ba4ed707b3, 78da0f9802f8047d8b62d14230d1edb1b15561e9, 7b39cd57a64ad546b69a8fb403a8426059367f3d, 2180b1a15b698dc223f353166a1c2871309e1eeb, 8194500f82f336beaa7246cca03859ffbb9b5823, c73a7ec5b22571d78f88729cf619cbdeca3f8d74, b40d6c48b0802b5055159ee0f1194b652d6bc017, 811d197754f5fe7ce37877bcc64702e7c356c702, 719057f8c06a6b7006b5720ebb2b8c926561e077, 1a914b0ed4d921c73ea5c17b9caaaa0e5fba7f4e)
• :white_check_mark: login: otelbot[bot] (b2737864c42d9442f9fc0f45b3ae5424ae0f71f4, c84ab3d537d88b30e78ab55855dd7cb1ef4216d9)

[otelbot-java-contrib[bot]]

❌ The result from spotlessApply could not be committed to the PR branch, see logs: https://github.com/open-telemetry/opentelemetry-java-contrib/actions/runs/15303539997.

[Cirilla-zmh]

Update:

• Refactored the README by moving the given implementation instructions ahead of the manual setup ones.
• Regarding the generic parameters in AttributesGetter: I believe we have to keep them this way because we're reusing the definition of AttributesExtractor from the instrumentation. If we restrict the type to a specific interface, users wouldn't be able to define their own AttributesExtractor without resorting to explicit type casting. At this point, I think it's reasonable to provide an extensible and generic type here.
• Added tests for aliyun-mns-sdk ;)

cc @steverao @trask

[Cirilla-zmh]

Some feedback: reducing the complexity of AttributesGetter

[otelbot-java-contrib[bot]]

🔧 The result from spotlessApply was committed to the PR branch.

[otelbot-java-contrib[bot]]

🔧 The result from spotlessApply was committed to the PR branch.

[otelbot-java-contrib[bot]]

🔧 The result from spotlessApply was committed to the PR branch.

[Cirilla-zmh]

@trask Hey Trask, I've refactored the design, and we now have an implementation that's very similar to the one in instrumentation. Could you please take a look at it?

[github-actions[bot]]

This PR has been labeled as stale due to lack of activity. It will be automatically closed if there is no further activity over the next 14 days.

[Cirilla-zmh]

@trask Hi Trask, this PR is ready to be merged, but there's a legacy issue we need to resolve: should we keep maintaining it in this repository or move it to java-instrumentation? Let me know your thoughts.