[improve][broker] Avoid redundant Key_Shared consumer set

[lhotari]

Motivation

The Key_Shared dispatcher records every consumer selected while filtering a read batch in a dedicated HashSet. It only queries that set if the batch dispatches no entries, to decide whether another consumer could make progress through look-ahead.

The existing per-batch permit map is populated for the same selected consumer before every dispatch decision. Its keys therefore carry the same membership, making the extra set and one hash-table insertion per selected entry redundant.

In an exact post-warmup broker profile, the redundant HashSet.add path accounted for 201 CPU leaf samples inside filterAndGroupEntriesForDispatching.

Modifications

• Remove the separate selected-consumer set.
• Use the existing permit-map keys in the final look-ahead membership check.
• Keep blocked-consumer and blocked-hash bookkeeping unchanged.
• Add coverage verifying that a selected consumer without permits does not prevent look-ahead from finding another consumer with permits.

Verifying this change

The focused sticky dispatcher, slow-consumer, and shared permit-accounting suites passed, as did broker Spotless, Checkstyle, and ./gradlew quickCheck --no-daemon.

An actual production-path JMH benchmark with 1,000 entries and ten consumers improved the healthy dispatchable batch from 84.3 to 77.2 us (-8.4%). Allocation fell from 67.38 to 67.12 KB/op.

An end-to-end run used 500 producer connections and five Key_Shared subscriptions with ten consumers each. All 30 million fanout deliveries completed with no duplicates, ordering violations, or invalid messages. The targeted HashSet.add path fell from 201 CPU leaf samples in the preceding exact profile to zero. The single full run is used as correctness and CPU-attribution evidence rather than an end-to-end capacity claim.

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