We should take the work from #2432 and land it.

I think the following are needed:

• scope it down to just transaction flooding (so that we can land it without having to also analyze its effect on SCP traffic)
• analyze its failure modes, in particular what a bad actor can do and its behavior when during abnormal events (traffic spikes, nodes stalling, etc)
• analyze its interaction with flow control
• reconcile with our current "eager flooding strategy". In particular, we try to bias towards "surge pricing order" (that happens to change with CAP42), and we want to make sure that we're limiting the amount of transactions that we drop on the floor post pull when connected to a peer with low quality/fee transactions. This can be implemented later, but we need to have a way to do this.
• ensure that we have metrics available both a a macro level (application wide) and micro level (connection level, exposed via the "peers" endpoint). Related issue: expose individual peer information tracked by overlay via the peers endpoint #3041