TcpServer: timeout source returned to the pool twice after a TLS handshake (crash on shutdown) #306

In TcpServer.HandleConnection, with SslOptions set, timeoutSource is created for the TLS handshake and disposed (returned to the multiplexer's pool) in the handshake's finally, but not reset. If the connection then ends before the message loop assigns a new scope - the client disconnects after the handshake (MessageType.None), the transport is no longer connected, or the lifecycle token is canceled - the outer finally disposes the same scope again.

On shutdown the source was already disposed (the lifecycle token was canceled, so TryReset failed and Return disposed it); the second Return calls TryReset on a disposed CancellationTokenSource and throws ObjectDisposedException from an async void method, which terminates the process:

System.ObjectDisposedException: The CancellationTokenSource has been disposed.
   at System.Threading.CancellationTokenSource.TryReset()
   at DotNext.Threading.CancellationTokenMultiplexer.Scope.Return(...)
   at DotNext.Threading.CancellationTokenMultiplexer.Scope.ReturnAsync(...)
   at DotNext.Net.Cluster.Consensus.Raft.NetworkTransport.ConnectionOriented.Tcp.TcpServer.HandleConnection(Socket remoteClient)

While running, the same pooled source can end up in the pool twice and be handed to two connections, so a timeout of one can cancel the other's request.

Seen with 6.10.0 (and on develop): in our test suite with three-node TLS clusters started and stopped in one process, roughly one run in six to eight crashed. With the scope reset after the handshake, none of 30 runs did.

Fix: timeoutSource = default; after the handshake's finally, so the outer finally disposes only a scope of the message loop.