Fix distributed deadlock between two sessions

This code gets rid of holding a lock during the call to Send(). In general, it is a good idea not to hold locks while making potentially blocking operations.

I've seen the other pull request, which removes the lock when reading responder_ in HasResponder.

I think that is not correct solution: the responder_ member is a mutable property in Session, and as such needs some kind of synchronization for access. There is no real argument that this would work more than observing the fact that it doesn't seem to cause problems.

Another problem is that the Disconnect() method is also protected by the same monitor, and this patch makes sure that calls to Disconnect also succeed without having to wait for a long Send() to return.

At last, this is what the code in quickfixj does.
I agree that opening up for the application to take care of a send queue, if necessary, is probably a good idea.  It would be necessary to provide an easy to understand way to generate and use sequence numbers, however.

> This is still holding a same lock on the entire I/O operation – so that’s no change compared > to original situation.
>
> A separate dequeuing thread would be needed.

It is different in that the lock is held only while sending messages, and never taken otherwise. This means we can still receive messages and close the connection while a send operation is in progress.

The problem with the original code is that it deadlocks in high traffic situations.

Staffan