Split Peerset into reputation store & ProtocolControllers

[dmitry-markin]

The connection logic (connect/drop/accept/reject) is extracted from Peerset into ProtocolController and PeerStore. Each ProtocolController instance is responsible for a specific notifications protocol, and should allow customization of connection logic by protocols in the future. PeerStore is responsible for connection candidates and peer reputations.

Resolves #13531.

[altonen]

Did a first pass. There are some problems we need to address, especially regarding Peer. I hope we can get rid of it and just match on peer state and then perform the correct action.

[altonen]

I think this is going in the right direction. Some of code duplication should be removed if possible

[dmitry-markin]

@altonen I've reworked peer management using ideas from your prototype. Apart from a couple of places where I had to call self.peerset_handle.is_banned() instead of self.is_banned(), borrowing issues are gone. Implementation of alloc_slots() feels sub-optimal, but that's likely an inevitable consequence of separating peer reputation values and connection handling.

[altonen]

I think this is looking good already. alloc_slots() can be improved but could you write some tests to confirm this implementation works as expected?

[dmitry-markin]

... could you write some tests to confirm this implementation works as expected?

Sure, that was my plan.

[dmitry-markin]

The PR is ready for review. Relaxing requirements on possible messages in Notifications a little more allowed to get rid of ACKing, preserving the eventual consistency of peer views in ProtocolController and Notifications.

[dmitry-markin]

We definitely need a burn-in for this PR.

[altonen]

We definitely need a burn-in for this PR.

Versi burn-in would be nice

[altonen]

LGTM but let's merge it only after the burn-in is done

[melekes]