Receive loop can spin after a truncated datagram

Summary

Some targets read one datagram per `recvmsg` call instead of using `recvmmsg`: Apple platforms without the `fast-apple-datapath` feature, OpenBSD, NetBSD, Solaris and illumos, and from 0.6 also DragonFly BSD, Redox and GNU/Hurd. On these targets the receive loop set up its `msghdr` only once and looked at the `MSG_TRUNC` flag before checking whether `recvmsg` had failed. After a datagram larger than the receive buffer was dropped, a following `EAGAIN` still saw the old truncation flag. The loop then kept issuing non-blocking receives instead of returning `WouldBlock`.

When the receive buffer is smaller than a datagram that arrives, a remote sender can keep the task that drives the socket busy, before any QUIC packet authentication. The loop ends only when a later datagram fits in the buffer. Whether an application is exposed therefore depends on the receive buffer size it uses. Linux, Android, FreeBSD and Windows use other receive paths and are not affected.

The fix rebuilds the header before every `recvmsg` call and returns receive errors before checking the truncation flag. It is in 0.5.16 and 0.6.3.