Send fails in HyParView when a node is randomly selected to become passive

[aramallo]

This happens when a message is fast forwarded. The sending function checks we have a connection for Channel/Node, prepares the message and the sends. Concurrently the peer service might decide to demote the connection from the active view, by the time the sending function calls the gen_tcp the connection doesn't exist anymore.

The solution might involve the process of demoting to have several phases. First the peer marks the connections for the chosen node as transitioning to passive, at this point the connection still works but is no longer listed as available. All processes that already chosen the connection should be able to send messages.

The challenge is how to coordinate this with the other node to keep symmetric views and when to finally move the node to the passive view (killing connections). The solution for the timing might involve using a ref counting mechanisms for connections (ets counters or atomics) but we should try to avoid that as much as possible.