`Reader#hasMessageAvailable` give wrong value after `Reader#seek`

[aloyszhang]

Describe the bug
Reader#hasMessageAvailable is used for checking if there is any message available to read from the current position.
But in this case:

1. Reader#seek a time after the publish time of the last message
2. Reader#hasMessageAvailable still return true and Reader#readNext will be blocked
   It looks unseemly, Reader#hasMessageAvailable shoule gives false since there no more new messages to read.
   The reason it that Reader#hasMessageAvailable will finally call ConsumerImpl#getLastMessageIdAsync which just return the last messageId.
   Reader#seek has no effect on Reader#hasMessageAvailable.

Related issue [#7775 ]
To Reproduce

1. Reader#seek a time after the publish time of the last message
2. Reader#hasMessageAvailable still return true

Expected behavior
Reader#hasMessageAvailable shoule gives false if there no more new messages to read.

[sijie]

@aloyszhang Are you working on this issue?

[aloyszhang]

@sijie Yes, I'm working on this issue.

[lhotari]

@aloyszhang I checked the PR #7848 . It looks like the fix wouldn't help in my case. In my case, it's not about the seek time, but there are some race conditions that happen because of the behavior that the broker disconnects the consumer after a seek (a reset). Please check my comments in #5278 (comment) .

[aloyszhang]

@lhotari I have made some modify and pushed again.

[lhotari]

I have made some modify and pushed again.

@aloyszhang Looks promising. Good work.

Would it be possible to add test cases with ordinary message id seeks? For example a test case where there would be a fixed number of messages in a topic (for example just 3 message). When publishing the messages to the topic, their respective MessageIds could be stored. The test would then do a given number of reads (for example 100 times) where it first uses seek to go to one of the randomly picked message ids, checks with hasMessageAvailable that there's a message available and then reads the message and verifies that it's the correct message. This should be enough to show that the problem with seek + hasMessageAvailable has been resolved and doesn't run into some race conditions caused by the broker code that "disconnects all the connected consumers and then resets the cursor" (as described in #5278).