[rpc] Isolate internal listener resources from client backpressure #4856

Search before asking

• I searched in the issues and found nothing similar.

Motivation

Internal replication and control connections currently share the Netty network threads, request processors, and request-channel backpressure with client traffic. A slow client request can occupy a processor and fill its queue. RequestChannel then pauses every associated connection, including follower replication connections. This can delay replication and high-watermark advancement even when the replication request itself needs little processing time.

Configuring separate listeners does not currently isolate these resources: NettyServer supplies the same request channels and network event loop group to every listener.

Solution

When internal.listener.name identifies an entrance separate from external listeners, give internal and external traffic independent network event loop groups, request processors, queues, and existing queue-based backpressure. Reuse the same resource-management and request-processing implementation for both groups. Multiple external listeners should share the external resource group.

When internal and external traffic use the same endpoint, retain a single shared resource group. Select the topology from the existing listener configuration without adding an isolation enable switch or changing the wire protocol, authentication, authorization, or request ordering.

Preserve every existing metric name, label, hierarchy, request classification, timing boundary, and aggregation meaning. Existing request histograms must remain shared, and queue gauges must retain their existing processor-index and total-queue semantics without duplicate registration or double counting.

Anything else?

Regression coverage should exercise real RPC connections under a blocked or backpressured external workload and verify that internal requests still complete. Single-endpoint behavior, shared external resources, metric compatibility, and resource shutdown must also be verified.

This change isolates the existing RPC scheduling and queue-backpressure resources. It does not introduce a new TS memory-management policy or claim isolation from shared CPU, disk, business locks, or asynchronous executors.

Willingness to contribute

• I'm willing to submit a PR!