PoT gossip refactoring

[nazar-pc]

This is a small refactoring that essentially removed NodeClient and converted PotGossip into PotGossipWorker that is instantiated directly and unconditionally. TimeKeeper no longer intantiates gossip engine, it just has a handle to gossip locally produced proofs to the network. There is also a bit more type safety since we use PotProof instead of Vec<u8> as much as possible now.

I did not change initialization or anything like that here, just rearranged things.

Code contributor checklist:

• I have read, understood and followed contributing guide

[rahulksnv]

LGTM thanks

[rahulksnv]

We could potentially get rid of run() completely?, as it only proxies messages to gossip worker after this change

The producer thread can use something like https://docs.rs/tokio/latest/tokio/runtime/struct.Handle.html#method.block_on to directly send message to gossip worker

[nazar-pc]

block_on is a blocking operation, not sure how you want to use it here. fn run returns future that is driven by something external. If something external doesn't need it anymore (node is shutting down for instance), then future will be dropped.

[rahulksnv]

The producer thread is a std thread, does this currently:

            } else if let Err(error) = proof_sender.blocking_send(next_proof.clone()) {
                warn!(%error, "Produce proofs: send failed");
                return;
            }

I don't understand your concern

[nazar-pc]

blocking_send is happening from a dedicated thread, run is an async function. I don't understand what you're proposing here.

[rahulksnv]

Uh ok .. the proposal:

1. run() would just spawn the std thread and exit
2. The bounded channel would be shared between this std thread and gossip worker. The producer thread would directly send the proofs on this to gossip (several ways to implement this)

Or you can leave it as is, will make a follow up PR

[nazar-pc]

I temporarily abandoned Timekeeper as a data structure in the local WIP branch, didn't see the point in a struct, will have to see what to do about it once I get to connecting it with gossip again.

[rahulksnv]

I am not sure about initialize() happening both from the time keeper and the gossip components, particularly in the context of the node restart, etc that we talked about (this may be ok, but not clear right now). After 1860, 1861 the init path would be simplified, so it probably is fine then

[nazar-pc]

Next PR actually removed all initialization of gossip, I think I'll have to change it since initialization changes there as well.