Smarter reconnection handling for msg queues

[Wondertan]

Context

Messenger manages a per-peer queue of messages. Those queues are not cleaned up right now if a peer disconnects, which is technically a bug.

However, the goal is to allow queues to live for some configurable amount of time if peer disconnects, so once it reconnects the same queue is reused and writing of outstanding msgs restarts.

Unfortunately, there is a chance for messages to be lost, as any msg written to a libp2p stream can return a success, while in fact it was not send. This is happening because of the non-blocking API of stream writes in libp2p. I.e. a case possible where a connection can be closed right after a successful write, but the write itself was buffered and wasn't written to the closed connection.

Therefore, there is no precise way for Messenger to know which message has to be resent on reconnect, because a msg could be written to the stream, return success, but in fact lost forever.

[Wondertan]

The PR was merged but it doesnt really fix the issue, as it much harder and requires deeper changes in the way muxer works or this ideas is simply no feasible. Basically, stream should not buffer Writes, so that writer knows if a message was sent or not, but there are reasons to keep writes buffered.

[Wondertan]

The solution to the problem, could be an additional error channel attached to each stream in the implementation of most of libp2p muxers. The Write implementation, after writing to a buffer or a write channel, would block on the new error channel and wait until the session/connection of the muxer notified the stream back with nil or error. This way libp2p streams would be able to provide a guarantee that any msg written with success was also written to the underlying session/connection. However, this makes all the writes to the libp2p streams blocking, and there might be reasons to keep them so.