Improve error handling in on_accept

[sridmad]

1. Handle operation_abort error code. Indicates that the listen socket is closed

2. Handle exceptions thrown by start. Setting ssh context can throw exceptions, catch them, close the connection and continue handling connections.

3. Continue accepting new connections for any error_code other than operation_abort.

[sridmad]

@kavyako , please review

[sridmad]

Addresses #742

[garethsb]

Is it possible to receive operation_aborted for a temporary error condition that shouldn't cause the listener to stop accepting? Conversely is there any other error code that indicates an unrecoverable error that should cause the listener to stop accepting?

[sridmad]

@garethsb-sony, I found a different mechanism to detect connection closed in a asio sample at https://github.com/chriskohlhoff/asio/blob/master/asio/src/examples/cpp03/http/server/server.cpp. However this pattern does not handle all cases correctly. There are cases where on_accept is with operation_aborted before m_acceptor.is_open() is able to detect that the connection is closed. Most probably due to a race in the shutdown case.

My change will not regress existing behavior but at least allows the server to continue listening on other errors while having the same behavior for operation_aborted. I was not and expert on Linux and was not able to find much information about other cases that can result in operation_aborted.

[garethsb]

I'm not sure it's necessary to take the lock again when spinning off another async accept?

[sridmad]

@garethsb-sony, without the lock, m_acceptor can be reset between the null check and using the variable.

[garethsb]

Thanks. OK - yes, m_acceptor is reset under the mutex in hostport_listener::stop. Now I'm wondering whether hostport_listener::start should also take the lock in order to set m_acceptor.

[sridmad]

@garethsb-sony, I cannot see anyone using an instance of hostport_listener before Start completes. For all practical purposes Start is the constructor for the type and having multiple threads calling Start on the same instance is a bug. Existing calls to Start on this type all ensure that Start is called from only one thread and other members are not called unless Start has completed.