`HttpServerRef` exits accept loop when HTTP client closes connection before being accepted.
When a client connects to `HttpServerRef` and then closes the connection before the server had a chance to `accept` and register it, various POSIX errors may occur. These errors are currently treated as critical and non-recoverable, resulting in the accept loop being exited. Future connection requests would no longer be handled by the server; clients start filling up the listener backlog until full, then get rejected.

Ran into this some time with a HTTP client that kept retrying to access a REST API,  but the response computation taking longer than the retry period.  The issue does not show consistently, usually took about 30 minutes to reproduce.

List of known errors that may indicate this problem during `server.instance.accept`.
- accept: [ECONNABORTED]
   A connection has been aborted.
- accept: [EPROTO]
   A protocol error has occurred.
 - setsockopt: [EINVAL]
   The specified option is invalid at the specified socket level or the socket has been shut down.

Note that the presence of these errors indicates that a client connected but immediately closed.
It may still be worthwhile to pass this information onward from `stream.nim` instead of hiding it there.

Unfortunately, the specific errors are underspecified and platform specific (there may be additional ones).
Furthermore, the current implementation hides the errors behind a generic `TransportOsError` that no longer carries info about the specific syscall that failed. Note that this is in line with Nim, e.g., `createAsyncNativeSocket` in `asyncdispatch.nim`.

Ideally, programming errors (i.e., accepting a socket NEVER works) should be caught by assertions next to the call site, and only intermittent socket-specific errors should bubble up as `TransportOsErrors`. e.g., the non-blocking syscall would be a point for an assertion / this is not something that typically fails on just some sockets but not on others.

On top of the errors during `accept`, the `HttpServerRef` furthermore also exits the accept loop when the client closes the connection between the socket being accepted by the server, but before the client's identity is being fetched for the first time (before it is cached).

List of errors that may indicate this during the initial `transp.getId()` .
- getpeername: [EINVAL]
  The socket has been shut down.
- getsockname: [EINVAL]
  The socket has been shut down.

Related PR that fixes this: https://github.com/status-im/nim-chronos/pull/232
However, not sure if this problem also affects non-HTTP servers.
