[Feat] Limit peer pool size, remove banned peers from the pool

[ljedrz]

This PR is larger than I expected, so I decided to also create an issue for the remaining bits.

The changes are as follows:

• 650bcd8 - a prerequisite for aligned peer removal, and a useful change on its own; it just replaces the Router's Resolver with the one from the Gateway, using it for both entities
• 0d553b3 - makes peer removal distinct from its status downgrade, and aligns it between the Gateway and the Router, moving all auxiliary cleanups to the Disconnect trait which already handles those
• edabb73 - causes bans to prune the related peers from the pool
• 2a58ca2 - disallows outbound connections to IP-banned peers; it's already done in the handshake, but this makes it more performant
• 52f0934 - removes any banned IPs from inbound peer lists
• dfd553c - aligns the way candidate peers are inserted in both the Gateway and the Router, and makes it so that validator peer lists go through the peer pool before any connection attempts are made to them (in order for the heartbeat to fully control that process)
• 07763e5 - applies candidate peer slashing when new entries are about to breach the peer pool size limit

Open points:

• the exact values for the new limits
• this approach doesn't guard us from breaching the peer pool size limit when we receive a direct connection from an unknown peer; if we want to do so, I propose to do it as a follow-up, as it may also be a larger change than one might expect (if it is to be performant and idiomatic)
• there is a minor difference between how the Gateway and the Router filtered dev addresses (!is_local_ip vs !is_bogon_ip); I left the latter for now, but this may need to be distinguished based on Self::OWNER if we see any test/devnet issues

Closes #3872.
CC #3888.

[kaimast]

Looks great to me. I left multiple small comments that we can hopefully address quickly.

[ljedrz]

All review comments have been addressed, and staging was merged into the PR.

[vicsn]

LGTM, let's await Kai's review before merging

[kaimast]

It still appears to me that there are potential race conditions. Read-write dependencies exist in a few places (e.g., when truncating the peers to add based on the existing number of candidate peers), but not for all of them a lock is held the entirety of the critical section.

If you think these race conditions are unlikely or the outcome is benign, e.g., a node might end up with some candidate peers too few/many, then I am okay with merging it.

For the line where it inserts new candidate peers, I would still prefer if it (double) checks it will not overwrite an existing connected peer. Using match peer_pool.entry(addr) should not be more expensive than peer_pool.insert(addr, ..).

[ljedrz]

I've given it some thought, and decided to hold the write guard for the entire duration of insert_candidate_peers; the RwLock we're using implements eventual fairness, and we can easily guard ourselves against unsolicited peer lists if we ever suspect it to be an issue.

They wrote they are ok with merging