This was a bug regarding the following state transition functions:
Free -> Connected
Free -> Move
Inbound connections go directly to Connected (1) and Move (2) in the
following cases- when an inbound connection connects to us (1), when we
blacklist a peer due to missing dispatchers (2).
If we previously had a connection on the same port that was now marked
as HostState::Free in the hostregistry, this would create a panic.
We introduce a new HostState called HostState::Free, which means a host
is freely available for use. This fixes race conditions where multiple threads could try to delete
the entry (using the unregister() call) at the same time.
Fixes a bug on seedsync_session where due to us quickly stopping
channels after they are formed the Subscription would occasionally miss
the channel.stop() event.
We previously deleted the call to `unregister()` after the refinery is
successful on a16dd562d9.
It was considered redundant since the `unregister()` call happens in
`subscribe_on_stop()`, which for refine session is called directly after
the refinery process finishes (after `channel.stop()`).
However, in a highly async environment the `unregister()` call in
`subscribe_on_stop()` can be called before the call to `move_host()`, meaning
that the host would then be stuck in the `Moving` state.
We have fixed this by specifying that `unregister` should only be called
in `subscribe_on_stop()` to peers that are not part of a refine session.
We seperately call `unregister` after `move_host` in the refinery.
This commit also fixes some documentation.
Note: the call to `unregister()` is highly fragile and can lead to race
conditions. We are working to replace this with something more robust
(like `tombstone()`).
