rangefeed: reduce goroutines for rangefeed registrations

[erikgrinaker]

With the mux rangefeed protocol and the rangefeed scheduler in #107553, the only remaining O(ranges) goroutine scaling in rangefeeds is with registrations. These are basically responsible for buffering and sending events from the processor to the gRPC stream. We currently spin up one registration goroutine per range/client pair both for the plain and mux rangefeed protocols. In both cases, this is wasteful:

• plain rangefeed: there's already a goroutine spawned by gRPC to handle the Node.RangeFeed() request that's just sitting around waiting for a future to complete. This goroutine could be reappropriated to do the actual event processing instead of spawning an additional one.

• mux rangefeed: all the registrations fan in to a single stream anyway, so we could just have a single goroutine per mux that receives events from the processors and passes it on.

There is a draft PR for this in #109667, but it unfortunately won't make it in for 23.2. We should get it into 24.1 instead -- in that case, we may remove the legacy processor and only use the scheduler (and possibly even the mux), which would significantly reduce the complexity here since we won't have to support all permutations.

Touches #96395.

Jira issue: CRDB-31426

Epic CRDB-37519

[blathers-crl[bot]]

cc @cockroachdb/replication

[blathers-crl[bot]]

cc @cockroachdb/cdc

[blathers-crl[bot]]

Hi @exalate-issue-sync[bot], please add branch-* labels to identify which branch(es) this GA-blocker affects.

_{:owl: Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}