Implement join ring op

[iduartgomez]

Add and finalize the ring protocol related ops, including the following functionality:

• complete net join op between 2 nodes with 0 hops (direct between gateway and connecting peer)
• complete net join op after randomly traveling through the network to fetch more nodes to avoid local disconnected clusters
• retry joining other gateway(s) upon initial failure
• pruning dead connections (this is a responsibility of the connection manager now and we will propagate that dropping through the application somehow else)

Include tests and pass them all:

• Happy path unit test state transitioning.
• Broadcast state transition unit test.
• Connect one node and a gateway unit test.
• Connect several nodes in a network unit test.
• Detect unavailability of any network gateways unit test. (I don't think this makes much sense to cover at the ring level either, more at the connection manager layer)

[iduartgomez]

Resolved a lot of issues but still some unresolved stuff:

• When proxy propagation is done, if it fails, backtrack and try new nodes until they succeed or exhausted. Alternatively, or additionally, try to spread to more than 1 host per hop.
• When nodes join the network, and as gateways tend to be filled, those may be placed at the edges of the network. Making the network loosely connected at some nodes and "unreachable". In theory this should be fixed by propagation, but I believe due to the first point we reach some situations where the network is "stalled" and new nodes cannot connect any more.

[iduartgomez]

After some discussion, we may want to change how things are done in the future re. join op, between other alternatives.

• Send, from the requester, multiple join requests to the gateway, in parallel, which return independently. For this to work we should work out a way to only assign one location per requester for subsequent/parallel requests (this implies, at the very least, searching at the gateway for those parallel requests).
• Return immediately, at each hop, if the connection was accepted or not. This can be done directly to the requester without having to rewind the connection chain per hop (as is done now), in fact is a good idea to change this and return immediately to the requester. Important: when we done real network connection, verify that the requester peer is reachable by the node which potentially is accepting the connection, otherwise don't accept it.
• Do multiple requests from each hop, this could not return immediately which adding back significant complexity to the callback chain in order to synchronize the number of connections accepted so far, or adding additional verification (we already do that so maybe we would just not verify the "excess" connections). Although the first change may run into similar problems and we potentially have to discard potential connections.

This could be also probably solved by splitting evenly and keeping track of the number of accepted connections so far. All in all still will need to improve this, but leaving any additional work for when we start adding real networking.

[iduartgomez]

Will come back to do the improvements in other issues/pr for now this is "good enough".