Honour a de-armed READABLE in read_more; drop the fcntl pair after SOCK_NONBLOCK

[jimmyolo]

Two small fixes found while building a Node.js net implementation on uSockets (epoll backend, upstream pinned at 2353808).

1. loop.c: stop read_more once the poll mask no longer has READABLE

The re-read after a full 512 KB recv is kept — the comment's reason (a hangup queued in the same iteration closing the socket before the data is drained) still holds. The change is one extra condition: if on_data de-armed LIBUS_SOCKET_READABLE via us_poll_change, which is how a consumer says "stop reading", the loop honours it instead of reading until close.

if (length == LIBUS_RECV_BUFFER_LENGTH && s && !us_socket_is_closed(0, s)
    && (us_poll_events(&s->p) & LIBUS_SOCKET_READABLE)) {

Before this, a consumer that paused from inside on_data kept receiving 512 KB per pass for as long as the peer's window stayed open. Reproduction: a peer that drains in pulses against a 64 KB high-water mark queued 2.8 MB (Node's own net peaks at 124,928 bytes on the same peer); after the guard the peak is exactly one LIBUS_RECV_BUFFER_LENGTH. A peer that never reads does not show it, since the window closes — which is why it hid.

AsyncSocket.h:57 in uWebSockets de-arms READABLE the same way, so it should benefit too.

2. bsd.c: skip bsd_set_nonblocking on sockets created with SOCK_NONBLOCK

bsd_create_socket and bsd_accept_socket already pass SOCK_CLOEXEC | SOCK_NONBLOCK where the platform defines them, and then call bsd_set_nonblocking anyway: F_GETFL + F_SETFL on a descriptor that is already non-blocking. That is four fcntl per connect+close (client socket plus accepted socket) that do nothing. Under strace -c, 4.00 → 0.00 per connection. The #else branch keeps the fcntl pair for platforms without the flag, under the same #if that adds it, so the two cannot disagree.

Both changes are being carried as build-time patches downstream (https://github.com/jimmyolo/u-socket/issues/140); happy to split them into two PRs if preferred.

[uNetworkingAB]

what kind of perf. do you see with your net.Socket, net.Server kind of reimplementation vs. Node.js's own?