Swap back to a blocking udp socket, test shutdown(2)

[nbrownus]

Before #1654 the Linux UDP reader used a raw blocking socket with a direct recvmmsg loop. #1654 switched to a net.UDPConn + syscall.RawConn netpoller path to get a clean shutdown. On many-core hosts, netpoller constantly parks and wakes the reader goroutines, and the resulting scheduler churn (findRunnable/lock2/futex) roughly halves UDP throughput. A 16-routine test on a 64 vCPU host fell from ~28.5 Gbps to ~13 Gbps, scaling routines beyond 8 made each perf test progressively worse.

This restores the blocking read, which parks the worker thread in the kernel and brings throughput back to ~28.5 Gbps with the churn gone entirely. Close() sets a closed flag and calls shutdown(2), and the read helpers translate the resulting wake into net.ErrClosed, matching the darwin/generic/windows paths.

The subtlety that sank an earlier blocking-plus-shutdown attempt (#1591, part of the now-closed #1375) is that once a socket has received a packet, shutdown(2) wakes recvmmsg with n>=1/Len==0 rather than n==0, so keying teardown off the message count spins forever; keying it off the closed flag handles every wake shape.

Also added some tests to make sure we correctly shutdown on linux in all situations.

I left runtime.LockOSThread() out because it increased scheduler pressure and made per packet cpu utilization go up in my testing.