Tests for small network

[marc-casperlabs]

This PR brings some drastic changes on how the reactor is run: Instead of having a mostly opaque run function, we now use a state-preserving Runner instead that can be interrupted.

This changes little for production use, but it makes it possible to interrupt and resume event processing of a reactor, controlling its progress from the outside (sans IO tasks). This is very useful when writing tests, which can be expressed very naturally:

   let mut net = Network::new();

    net.add_node().await.unwrap();
    net.add_node().await.unwrap();

    timeout(
        Duration::from_millis(1000),
        net.settle_on(network_is_complete),
    )
    .await
    .expect("network did not fully connect in time");

This PR demonstrates how to do that, for an example look at tests.rs of small_network, which implements a tiny testing reactor and a networking structure that can run many of these.

Other notes:

• The tests aren't completing successfully at the moment every time, which I might be due to bugs in either the testing code or small_net itself, this is naturally the next item to be fixed.
• The testing code for the network and some other functions from small_net's test.rs could be reused for testing other components, as it provides a generic interface for running multiple nodes until a condition holds true.
• The next step is usually adding model-based/property-based testing, for example generating a series of events to execute ("Node A joins", "Node B joins", "Node C joins", "Settle", "Node B drops") and checking whether the invariant (network fully connected) holds. These sequences can be randomly generated. With a bit of effort, it should be possible to have robust set of networking tests this way.

Naturally this PR is still a WIP.

This has turned up a few issues already that were present before, but I want to fix these in subsequent PRs.

[goral09]

I think this shows a downside of the current reactor encoding - namely that the Event is an associated type. It means that dispatch_event is dependent on the type of the Event and it will influence how the events are dispatched - where they go, how they're handled (delayed, rejected, etc) but this won't let us test the system as it will run in production. We would be testing a "test reactor".

[marc-casperlabs]

That's fine, I think. We're not testing the reactor here, but the networking component!

[marc-casperlabs]

So having a bespoke reactor just for doing that seems entirely reasonable to me. Consider it a test rig for a part. When testing car engines, they're initially not put in a car, but on a test stand!