[fix][client] Avoid exception in ConsumerImpl hasMessageAvailable before first receive

[void-ptr974]

Fixes #25837

Motivation

ConsumerImpl.hasMessageAvailable() can throw UnsupportedOperationException: Unknown MessageId type: null when it is called before any message has been dequeued from a consumer created through newConsumer().subscribe().

hasMessageAvailable is not part of the Consumer public interface, but ConsumerImpl exposes it as a public implementation method. The public Reader API also delegates its hasMessageAvailable methods to the underlying consumer implementation. In the failing consumer state, startMessageId can be null, and the existing comparison path eventually calls MessageIdAdv.compareTo(null).

Modifications

• Handle the initial startMessageId == null state by querying the broker for the last message id response and comparing it with the subscription mark-delete position.
• Extract the mark-delete comparison logic so the existing latest/timestamp path and the null-start path share the same behavior.
• Use FutureUtil.unwrapCompletionException(...) when propagating failures from hasMessageAvailableAsync().
• Add regression coverage for the ConsumerImpl implementation method, the public Reader API path, and empty-topic behavior.

Verifying this change

This change added tests and can be verified as follows:

• Added SimpleProducerConsumerTest.testConsumerImplHasMessageAvailableDoesNotThrowBeforeReceive.
• Added SimpleProducerConsumerTest.testReaderHasMessageAvailableDoesNotThrowBeforeRead.
• Added SimpleProducerConsumerTest.testHasMessageAvailableDoesNotThrowOnEmptyTopic.
• Ran:

./gradlew :pulsar-broker:test --tests org.apache.pulsar.client.api.SimpleProducerConsumerTest.testConsumerImplHasMessageAvailableDoesNotThrowBeforeReceive --tests org.apache.pulsar.client.api.SimpleProducerConsumerTest.testReaderHasMessageAvailableDoesNotThrowBeforeRead --tests org.apache.pulsar.client.api.SimpleProducerConsumerTest.testHasMessageAvailableDoesNotThrowOnEmptyTopic --no-configuration-cache

Does this pull request potentially affect one of the following parts:

• Dependencies (add or upgrade a dependency)
• The public API
• The schema
• The default values of configurations
• The threading model
• The binary protocol
• The REST endpoints
• The admin CLI options
• The metrics
• Anything that affects deployment