Consider pulling in the "unfriendly peers PR suite", perhaps with a flag
About 3 years or so ago, the network had some unfriendly participants and @moneromooo-monero made a bunch of PRs with potential mechanisms to keep a node connected even in that kind of environment. 

I think the effort stopped, so these PRs have just been sitting there.

7297, 
7255
7135
5955
6935
6940
6946
7081

edited to add

6944


edited to add clickable links added by @SChernykh 

https://github.com/monero-project/monero/pull/7297 https://github.com/monero-project/monero/pull/7255 https://github.com/monero-project/monero/pull/7135 https://github.com/monero-project/monero/pull/5955 https://github.com/monero-project/monero/pull/6935 https://github.com/monero-project/monero/pull/6940 https://github.com/monero-project/monero/pull/6946 https://github.com/monero-project/monero/pull/7081 https://github.com/monero-project/monero/pull/6944

To me, the logic of the PRs seemed sound, and they even received reviews. Thus, my conclusion regarding their unmerged status is that no one really tested them.

In lieu of testing (though I guess that could be done), these could be integrated with a flag that disables them. Thus, a node will run with them on as default. But if there happens to be an unexpected behavior, folks could disable the features. 

though i guess it could be argued that the daemon should ship with them off by default, and folks could switch it on. 

but defaults. 

( in addition, merging them would also make it easier to test, because ppl could just flip flags instead of compiling fancy PRs). 

ooooh, or maybe the flags could have varying levels of these measures. Because, the counterpoint to the above point is that by leaving them as PRs, we could test them 1 at a time....

well thanks for reading. 

--friendly-peers [0-4]         set network friendliness level. 0 = least friendly (all countermeasures active), 4 = most friendly (no countermeasures active). 

.... or this has already been done and i just missed it. 