Stream coordinator: optimise connection DOWN noconnection handling

[kjnilsson]

The Root Cause of the CPU Starvation

When a node goes down, the stream coordinator receives a {down, Pid, noconnection} command for every single client connection that was on that node (e.g., 20,000 connections).

For Single Active Consumers (SAC) used by super streams, the coordinator handles these down events by setting a node_disconnected_timer_effect. When this timer expires, it calls presume_connection_down/3 to clean up the consumer.

Here was the fatal flaw in rabbit_stream_sac_coordinator.erl:

When the initial down event was processed, the coordinator removed the connection from its pids_groups index (which maps a connection to the specific stream groups it belongs to).
When the timer expired a few seconds later, presume_connection_down was called. Because the connection was no longer in the pids_groups index, the coordinator had to iterate over every single group in the entire system to find where that consumer belonged.
If you have 20,000 connections disconnecting and 1,500 super streams (with 4 partitions each = 6,000 groups), the state machine was forced to do: 20,000 timeouts * 6,000 groups = 120,000,000 iterations

Inside each iteration, it was doing map lookups and list folds. This massive O(N * M) operation completely CPU-starved the single-threaded Raft state machine, causing the 30-minute delay where it couldn't process any other commands (like electing new stream leaders)

[kjnilsson]

rabbitmq-server-windows-4.2.0+beta.4.773.gcaadad0.zip

windows release artefact for user testing.

[kjnilsson]

#16340

This is the primary issue. This PR may not address everything.