Make libuv server api semantically similar to asio

[uatuko]

This is essentially building upon the work done in #42 and #44, which allowed the server to run using an external libuv event loop. But instead of using an external loop this change allows the internal uv loop to be run externally or add external events to the loop.

Main advantage of this change is that it makes the libuv server API semantically similar to asio server API, without removing functionality. It also makes the code a bit simpler since we don't have to check if it's an external loop or not.

[uatuko]

@tchernobog thoughts?

[tchernobog]

@tchernobog thoughts?

I think in general this is a good change. Thanks! The only item where I am thinking that it is a bit asymmetric, is that:

The socket handler must be already bound to a network address and will be closed when the server stops.

On one hand, we assume the initialization is done by an external entity. On the other, responsibility for de-initialization is moved to this object. I wonder if there are good use cases for reusing the socket or other reasons to avoid passing ownership. In that case closing should be up to the caller.

Otherwise, as a compromise, I would prefer if at least the parameter had type uv_os_sock_t&& sock so that it is clear it is moved at the call site by an explicit operation.

[uatuko]

Otherwise, as a compromise, I would prefer if at least the parameter had type uv_os_sock_t&& sock so that it is clear it is moved at the call site by an explicit operation.

I did think this would be better to have uv_os_sock_t&& but wasn't sure if there's a case where the caller would want to keep the ownership of the socket. I'll make the change as suggested 👍.