Is your feature request related to a problem? Please describe.

See #79215. At time of writing, MsgApp is not subject to admission control. Direct throttling at the receiver would lead to quota pool fulness and thus throttling at the user. While this may be desirable in some settings (i.e. a marginally slower follower that without such throttling would fall further and further behind), in practice a big problem is posed by stores that are so slow that they have an unacceptable effect on latency if taken into account for throttling.

Describe the solution you'd like

We should consider such stores as "non-live" for the purposes of replication. Concretely, they ought to be treated like followers in StateProbing (which is in (*RawNode).Status().Progress[replicaID].State); raft will only append to them ~once per second until they acknowledge. By artificially treating followers as probed as long as their (gossiped, in this experiment) store stats indicate that admission control on them isn't throttling, we can cheaply emulate the behavior of a "real" flow control mechanism (#79755) that necessarily would have to be more complex (multi-tenancy, priorities, etc).

Essentially the intuition behind this approach is that "a follower that isn't "live" for the purpose of quickly acking MsgApps should be treated as absent. In the experiment we are substituting "live" for "has no inverted LSM as determined by admission control" which is a sensible first approximation. A more complete solution (which is out of scope here) might be based on the store's recent measured write throughput which leaseholders can use to shape traffic to the node. However, this is verging into distributed rate limiting (a slow store will have leaders on many other stores; how do they coordinate who gets to go first) and is out of scope here. (I'll point out that we already do a form of distributed rate limiting for the tenant request units, so some reuse might be possible).

Describe alternatives you've considered
There are possibly other alternatives, which should be linked into the table in #79215.

Jira issue: CRDB-16308

Epic CRDB-15069