feat: accept until EAGAIN per poll round

[BulaBula-zy]

Summary

The listener is registered with level-triggered epoll (EPOLLIN, no
EPOLLET), and server.OnRead currently accepts exactly one connection per
event. Under a sustained burst of new connections, every pending connection
therefore costs one full poll-loop round trip (epoll wake-up + dispatch), so
accept throughput is bounded by that round trip rather than by the accept
syscall itself.

This change loops Accept() until the accept queue is empty
(EAGAIN | EWOULDBLOCK, reported by Listener.Accept as a nil connection with
nil error), so one poll round drains the whole backlog.

Prior art: Go's net package, nginx (default) and libuv also accept only once
per event — but they register listeners with edge-triggered epoll, where each
newly queued connection generates a fresh event, so they don't pay a re-fire
round trip per pending connection. netpoll uses LT, so it does. (Switching
the listener to ET is a larger, riskier change; this PR is the smaller step
and works under either trigger mode.)

The existing error handling (out-of-FD delay-and-retry, closed-listener
shutdown) is preserved unchanged; only the accept path is looped.

Functional tests (in-repo, real loopback connections)

• TestAcceptUntilEAGAIN_OneRoundAcceptsBurst: 64 fully-established
  connections parked in the kernel accept queue are all accepted by a single
  OnRead round. Fails on v0.7.5 (accepts 1 of 64), passes here — this is
  the discriminating regression test.
• TestAcceptUntilEAGAIN_NoInfiniteLoopOnEmptyQueue: OnRead returns
  immediately (nil) on an empty queue; no busy spin.
• TestAcceptUntilEAGAIN_ConcurrentClientsAllServed: 200 concurrent
  dial-write-echo clients through the real poll loop, all succeed.
• TestAcceptUntilEAGAIN_IdleConnectionNotStarved: a long-lived connection
  stays responsive during a 100-connection accept burst.

Validation commands and results:

go test -count=1 ./...                                 # PASS (Linux)
go test -race -count=20 -run 'TestAcceptUntilEAGAIN' . # PASS (Linux, 20x)

The same test file against v0.7.5 fails exactly the discriminating test:

--- FAIL: TestAcceptUntilEAGAIN_OneRoundAcceptsBurst (0.13s)
    one OnRead accepted 1 of 64 pending connections

Benchmark

BenchmarkAcceptSteadyThroughput (included in this PR): 400 workers
continuously dial-and-close against a real EventLoop for a 3s window;
throughput is counted server-side in OnConnect, so the metric is immune
to client-side ephemeral-port exhaustion.

Machine: Linux 6.8.0-136-generic (Ubuntu 22.04), x86_64, Intel Core i7-14700
(28 logical CPUs), Go 1.23.4, fd limit raised to 65535.

Command (per run):

ulimit -n 65535
go test -count=1 -run '^$' -bench BenchmarkAcceptSteadyThroughput \
    -benchtime=1x -timeout 60s .

Results, 10 runs each (server accepts/sec):

run	v0.7.5 (accept 1/event)	this PR (accept until EAGAIN)
1	19068	28382
2	17512	28332
3	17207	27392
4	20146	28194
5	19193	28455
6	18977	28310
7	19466	28305
8	20599	28382
9	19472	28205
10	20381	29285
mean	19202	28324
median	19330	28321
min-max	17207-20599	27392-29285

+48% mean; the ranges do not overlap (v0.7.5 max 20599 < this PR min 27392).
v0.7.5 also shows higher run-to-run variance; this PR is stable within ~7%.

Why count server-side, not client-side

A client-measured dial rate under this load shows ~0.9% "dial failures" on
this PR vs ~0% on v0.7.5. Those failures are
connect: cannot assign requested address — client ephemeral-port
exhaustion: the faster-accepting server makes the client establish
connections faster until the client runs out of local ports. It is a client
artefact, not a server regression; server-side accept counting shows this PR
is strictly faster, never slower.

Safety

• listener.Accept returns (nil, nil) on EAGAIN/EWOULDBLOCK, so the loop
  always terminates: it returns on an empty queue, or breaks on a real error
  into the pre-existing error path (out-of-FD retry, closed listener), which
  is unchanged.
• The listener fd is non-blocking (SetNonblock in CreateListener), so
  Accept never blocks inside the loop.

Open questions

1. The accept loop is unbounded: if the connection arrival rate persistently
   exceeds the accept rate, the loop never sees EAGAIN and the listener's
   poll goroutine starves the established connections that share its poller
   (pollmanager.Pick assigns the listener and connections to the same poll
   pool). libuv caps its read/write loops at 32 iterations for exactly this
   reason ("prevent loop starvation"). No starvation was observed in
   TestAcceptUntilEAGAIN_IdleConnectionNotStarved up to ~28K accepts/sec,
   but a per-round cap would be a trivial follow-up if reviewers prefer the
   safety margin.
2. Alternatively the listener could be registered edge-triggered like
   Go/nginx/libuv — a larger change with ET-specific concerns on the read
   side as well. This PR keeps LT and just amortizes the wake-ups.

[CLAassistant]

All committers have signed the CLA.