Do not give up the queue because one accept failed

[SimonCropp]

Listen returned on any SocketException from Accept, without looking at the error
code or at cancellation. That treats a failure of one accept as a failure of the
listener, and the two are not the same thing at all.

A peer that resets while its connection is still sitting in the backlog surfaces
exactly this way - WSAECONNRESET on Windows, ECONNABORTED on BSD and macOS - and
is common enough that Kestrel retries it by name. The consequence here is worse
than a dropped connection: the socket stays bound, so nobody else can take the
queue for the life of the process, and every later client lands in a backlog
that nothing is draining. PiperServer already continues in the same situation.

Return only when cancelled, or on OperationAborted and Interrupted, which are
how a stopped listener reports itself when the token has not been observed yet.

The tests pin the rule rather than the race. I wrote an end to end one first -
twenty abortive closes, then a real exchange - and deleted it after confirming
it passes with the old return still in place: on Windows the accept succeeds
and the reset surfaces later, during the read, which a different catch already
handles. A test that cannot fail is worse than no test.