Incoming federation transactions stack up indefinitely #9489
Description
Since #8342, we apply the federation ratelimiter after the transaction linearizer. The net effect is that, if we cannot keep up with incoming transactions, we allow them to stack up indefinitely (there can only be one thread inside the transaction linearizer, so we never hit the concurrency limit on the ratelimiter). This can use a lot of memory, and it's not the way matrix federation transactions are meant to work (if the remote gets behind, it should drop messages until it catches up).
It feels like the ratelimter is pretty redundant there. (Admittedly it still has some use as a true rate limiter rather than a concurrency limiter, but that's a bit of an edge-case.)
Should we instead be using a separate ratelimiter dedicated to incoming transactions?