UDP push in a loaded grid: the kernel socket buffer still overflows on key-frame bursts #253

Problem

PR #252 (#251) moved the udp:// receive to a thread of its own. In the U view a push now plays without socket drops. In the 3×3 grid the box is overloaded (load average ~26 on 4 cores on the Aceline box), and an H.265 1080p push at 8 Mbit/s still loses 30–80 datagrams per second. The test is in the PR #252 comment.

Where the datagrams go, from /stats.json → cells[U].udp over ~10 minutes:

• socket_drops 60859: the kernel socket buffer was full. An app can't go past rmem_max (256 KiB, so rcvbuf is 524288), and that holds only about a hundred datagrams by truesize.
• ring_dropped 3342 of ~633 000 received: the session thread didn't keep up with the ring.
• The receive thread runs at nice −8 (Thread.MAX_PRIORITY) and uses ~26% of a core in the grid, ~6% in the U view.

Ideas to try

1. Process.setThreadPriority(THREAD_PRIORITY_URGENT_AUDIO) for the receive thread instead of Thread.MAX_PRIORITY.
2. A cheaper receive: DatagramChannel into a direct ByteBuffer, no DatagramPacket and no address object per datagram. Joining a multicast group from a channel needs API 24, so multicast keeps MulticastSocket.
3. Native recvmmsg() through JNI, which reads a burst in one call.
4. Measure each on the Aceline box in the 3×3 grid against 2.18.3, with several runs per build: drops vary a lot between runs.

Not urgent. In the U view (one push, the usual FPV case) the drops are gone.