[improve][broker] Avoid read locks in Key_Shared consumer selection - #26591

Motivation

ConsistentHashingStickyKeyConsumerSelector.select acquires a shared read lock and searches a tree for every selection. Consumer membership changes much less frequently than messages are dispatched, so the lookup can use a precomputed representation that avoids the read lock.

Modifications

• Publish a snapshot of sorted hash points and their selected consumers after each membership update. Each lookup captures one volatile snapshot and uses binary search, preserving inclusive ceiling lookup, wraparound and empty-ring behavior.
• Keep membership changes, collision handling and assignment reporting under the existing locks. The snapshot arrays are never modified after publication; concurrent lookups observe a complete old or new mapping.
• Add boundary, collision and concurrent-membership tests, and a benchmark covering both selection and membership updates.

The snapshot retains an additional array representation of the ring and moves copying work to membership updates. This favors stable membership over frequent consumer churn.

Verifying this change

• Make sure that the change passes the CI checks.

Passed locally: spotlessCheck checkstyleMain checkstyleTest, quickCheck, benchmark packaging, and 20 scoped test invocations with no failures or retries:

• ConsistentHashingStickyKeyConsumerSelectorTest (14 cases).
• KeySharedSubscriptionTest.testOrderingWhenAddingConsumers, testRemoveFirstConsumer and testCheckConsumersWithSameName (six invocations).

KeySelectorLookupBenchmark uses the actual selector with 100 hash points per consumer and impact reporting enabled. Two forks, three warmup/five measurement iterations of one second, one thread, 512 MiB G1 and the GC profiler:

At 50 consumers, an add/remove pair allocates about 78 KB more. Both runs reached 100°C with thermal throttling, so these component timings do not establish a portable speedup or broker throughput gain. Local concurrency tests supplement the immutable-snapshot publication argument; they cannot prove every possible interleaving.

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

Selection uses volatile snapshot publication instead of the membership read lock. Membership mutation remains serialized; public APIs and dispatch ordering contracts are unchanged.