validator_discovery: less flexible, but simpler design

[ordian]

This PR implement and alternative design for validator discovery mentioned in #3035 (comment). As a bonus, it makes #3035 simpler to implement.

Instead of doing reference counting, we assume that the request contains the full list of peers all subsystems are interested in (per PeerSet). This is less flexible, but much simpler and hence less prone to bugs like #3038.

[ordian]

investigating why adder-collator test if failing

[eskimor]

I liked the formerly modular subsystem independent approach, but as it was only half baked anyway (subsystems would not have received PeerConnected events if another subsystem had issued connection requests earlier) and we don't need that modularity right now anyway, I think it is a fine simplification.

[ordian]

subsystems would not have received PeerConnected events if another subsystem had issued connection requests earlier)

Do you mean that subsystem A would issue a connection request before subsystem B even started? I don't think that was the case in practice, because A would have to wait for the first ActiveLeavesUpdate, by which time subsystem B should've started already. Also the PeerConnected event should be propagated to all interested subsystems from the bridge (dispatch_validation_event_to_all).

[eskimor]

It is definitely not an issue in practice. Just conceptually, if one subsystem issues connection requests later than another one, it would miss out on PeerConnected events, if it ignored it before it issued the connection request - for example. Or imagine a task that is started for some block, to track some stuff for a while and it issues a connection request - it would miss out on PeerConnected events if the connection was established already.

Either way all of this no longer matters with this simplification as we now rely on a single source of connection requests.

[ordian]

#3055 explains the failing test 😅

[tomaka]

validator_discovery.rs looks good to me

Note that sc-network also provides set_reserved_peers that does the same thing 😅
EDIT: the peerset contains the appropriate logic, but it's actually not exposed in the public API of sc-network

[eskimor]

Note that sc-network also provides set_reserved_peers that does the same thing sweat_smile

LOL, ok I think we should use that then. At least in a follow up.

[ordian]

Note that sc-network also provides set_reserved_peers that does the same thing

yeah, I think it's not exposed on NetworkService, also most of the time the deltas will be empty, so I decided to keep it as is for now