Use a dedicated thread for tcp listener

[pwojcikdev]

While I'm not aware of any problems with previous implementation, the async way of implementing tcp_listener was generally harder to understand and to evolve over time. It was especially problematic when making changes to other aspects of networking code. Given that our connections are long-lived and relatively infrequent, there is very little need for tcp acceptor code to be focused on performance and instead we should prioritize readability and maintainability. This modifies it to instead run on a single, dedicated thread and use blocking IO operations.

[clemahieu]

There are minor points to consider/discard/accept.

Overall I think moving to a single-threaded tcp_listener is a major benefit.

[clemahieu]

Should we close excess incoming connections or let the OS do it? If we don't service connections the OS will queue them up to max_listener https://beta.boost.org/doc/libs/develop/doc/html/boost_asio/reference/basic_socket_acceptor/listen.html
@dsiganos?

[pwojcikdev]

Can we test this behaviour with more sockets queued than the max capacity @gr0vity-dev?

[dsiganos]

I do not see a problem with this behaviour. This way effectively leaves the queueing to the operating system.
Another way would be to accept a socket and, if the limit is passed, close it.

[pwojcikdev]

For future reference: there is a problem with using blocking accept () on Linux. Closing acceptor doesn't guarantee that the blocking call to accept will return, as described in their documentation:

This function is used to close the acceptor. Any asynchronous accept operations will be cancelled immediately.

The blessed ASIO way of doing things seems to always be using async functions. Here I decided to go with use_future completion handler to make code as similar as possible to the threaded version and avoid callback spaghetti.

[dsiganos]

One thing that confused me is the name tcp_listerner although I don't know how to name it better (tcp_server_container maybe?).
I expected it to do just tcp listening but it does a lot more.
It also creates and manages the tcp_server objects and is responsible for keeping the tcp_server objects alive.

[dsiganos]

I do not see a problem with this behaviour. This way effectively leaves the queueing to the operating system.
Another way would be to accept a socket and, if the limit is passed, close it.

[dsiganos]

Also, the node does not stop when pressing Control-C because the the accept does not return probably because the io ctx is stopped by the signal handling code.

[pwojcikdev]

The issue with interrupt signal should now be fixed.

[pwojcikdev]

This seems to have triggered a new TSAN warning, I'm not sure whether it's a false positive or not. I'm going to move to coroutine-based implementation with a strand to avoid these problems altogether. The changes necessary will be minimal.

[pwojcikdev]

I'm splitting this refactor and coroutines into two separate PRs. The currently approved code provides a solid foundation to build on, but introduces a new TSAN warning that will be fixed by a subsequent coroutine PR.