refactor: split census into multiple types

[morph-dev]

What was wrong?

It's difficult to add features (e.g. #1501) to the Census in its current form.

Also, getting peers to gossip content to doesn't have to be asynchronous and as such, doesn't have to go over separate channel.

How was it fixed?

Split the census into multiple components, each responsible for small part:

• Peers - contains all peers (behind RwLock)
  • responsible for deciding when they should be pinged for liveness
  • in the future, it will also be responsible for holding additional information about peers (e.g. success/failure of other non-ping requests), and scoring peers according to those information
• Network - contains and propagates calls to Peers
  • responsible for pinging and discovering other peers
• 'Census' - the only entry point for users of Census (i.e. state bridge)
  • responsible for initializing networks and starting service that runs in the background
  • service is responsible for taking available tasks (provided by Network) and executing them
    • currently, this is only pinging and querying their routing table

New design allows Peers and Network (and easily Census) to be cloneable and shareable.

This PR shouldn't drastically change the behavior of the census, but it should make adding features easier in the future.

To-Do

• Clean up commit history and use conventional commits.

[KolbyML]

This PR shouldn't drastically change the behavior of the census, but it should make adding features easier in the future.

Are you planning to implement #1501 ?

[morph-dev]

Are you planning to implement #1501 ?

Yes, in future PR. Don't know in what exact form yet (mine, Piper's, both and compare, something else).

[KolbyML]

Are you planning to implement #1501 ?

Yes, in future PR. Don't know in what exact form yet (mine, Piper's, both and compare, something else).

Sounds good I will review the PR after the meeting 🫡

[KolbyML]

looks good, I noticed one thing that probably shouldn't be public but other then that things look good

[njgheorghita]

Looks good! just a few nits to consider

[njgheorghita]

nit is it worth adding an else here with a panic/error!? maybe not bc it'll get a bit convoluted, but then if we don't need an else do we need this if? there shouldn't be a case where we try to process a peer from an unactivated subnetwork... but this is very much a nit, fine to leave as is

[morph-dev]

I think there might be misunderstanding.

The if is not part of the regular code flow, but the special syntax for tokio::select! (more details here), and there isn't an option for else.
Unless you were thinking about else case of the tokio::select! statement, but then the comment doesn't make sense because code would already panic if else is not present and code execution would go there.
With the current implementation, this can happen if no subnetworks were provided in the init function, and now I added a check for that as well.

The if statements are needed with the current implementation because peer_to_process() would return None for uninitialized networks, forcing them to re-initialize and we don't want that for non-enabled subnetworks.

The original implementation was using selectors like this:

Some(Ok(known_enr)) = self.history.peers.next() => { ... }

(basically ignoring those None values) and re-initialization would be triggered when get_interested_enrs() would fail, causing that request to take much longer but still return empty set of enrs.

I believe that re-initialization should be detected and done as part of the regular census maintenance (and not be triggered by get_interested_enrs), and this is the cleanest way I found to do it.

I'm not sure if my explanation is clear. I think good understanding of what tokio::select! does under the hood is very important here, and I'm not sure how well I was able to explain my reasoning around it.