[fix][broker] Bound classic Key_Shared dispatcher replay queue look-ahead - #26677

Motivation

In the classic Key_Shared dispatcher, messages are assigned to consumers according to their sticky-key hash. If a consumer becomes slow and exhausts its available permits, messages mapped to that consumer cannot be dispatched. To keep other consumers making progress, the dispatcher continues normal reads and places these undispatchable entries into the in-memory replay queue.
This can cause broker OOM when all of the following conditions hold:

• There were 12 consumers
• consumer#xzqg9 was slow; other consumers have consumed all messages that they can.
• The dispatcher keeps reading entries and pushing messages(which should be consumed by consumer#xzqg9) into the redeliver queue since consumer#xzqg9's permits is 0.
• Eventually, the queue is too large, causing broker OOM.

Modifications

Let classic Key_Shared dispatcher support the configuration keySharedLookAheadMsgInReplayThresholdPerSubscription

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

If the box was checked, please highlight the changes

• 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