Recover pulsar wrapped message ids

[zeitlinger]

Summary

• Some Message implementations returned by pulsar-client (e.g. TopicMessageImpl from multi-topic consumers) wrap the underlying message and return null from getMessageId() on certain versions. Reflectively fall back to getInnerMessageId() or getMessage().getMessageId() on the wrapper to recover the id.
• Restores messaging.message.id attribute for PulsarClientTest.testConsumeMultiTopics.
• Main CI stays green because pinned pulsar-client 4.2.1 still returns a non-null id from the wrapper; the bug only surfaces on newer (unpinned) pulsar-client versions.

Test plan

• CI green on pulsar-2.8 javaagent tests

[Copilot]

Pull request overview

This PR updates the Pulsar 2.8 javaagent telemetry request wrapper to recover messaging.message.id when Pulsar returns wrapper Message implementations whose getMessageId() can be null (e.g., multi-topic consumer wrappers). It does so by adding reflective fallbacks to unwrap an “inner” message id.

Changes:

• Add a message-id extraction helper that falls back to reflective getInnerMessageId() and/or getMessage().getMessageId() when Message#getMessageId() is null.
• Update PulsarRequest to use the new extraction logic when resolving the message id.

[laurit]

Main CI stays green because pinned pulsar-client 4.2.1 still returns a non-null id from the wrapper; the bug only surfaces on newer (unpinned) pulsar-client versions.

by now the dependency has been update and CI is still green. Are you sure that the issue starts with 4.2.2? The latest dep test with multiple topics has been flaky for a while. Were you able to reproduce this locally?

[laurit]

when we use reflection we typically look up the method only once and reuse it for subsequent calls

[zeitlinger]

Good point — I pushed 6a0b6e7, which caches the reflective getInnerMessageId / getMessage lookups per message class via ClassValue, so we only pay the lookup cost once per wrapper type while keeping the fallback fail-safe.

[zeitlinger]

I was able to reproduce the null-message-id behavior locally on a wrapped Pulsar message, but I don't have enough evidence to claim a precise first-bad version like 4.2.2. The actionable part for this PR is the wrapper behavior itself, so I pushed 6a0b6e7 to cache the reflective accessors and keep the fallback cheap on repeated calls while CI reruns on the updated branch.