Use sendmmsg to reduce system call overhead

[Ralith]

I noticed sendmsg was 35% of the flame graph for the large streams benchmark, so I finally had a go at this. It yields a roughly 15-30% improvement in each one of the throughput benchmarks! Oddly, sendmmsg is still about 35% of the flame graph, and cranking the batch size way up doesn't seem to help any. We'll probably need to dive into libc or the kernel or even investigate generic segmentation offload or similar to make further headway on this particular bottleneck.

[Ralith]

Looks like macOS doesn't expose this; there's sendmsg_x, but the comments describe it as unstable. How do we feel about using that?

[Ralith]

Using the fallback for now, since sendmsg_x isn't even bound in the libc crate.

[Ralith]

Investigation suggests that the remaining sendmmsg presence is just how much time it takes to send UDP packets on Linux. Further optimization will have to come from elsewhere, or resort to userspace networking.

[djc]

Mostly looking good, some questions.

[Ralith]

sendmmsg isn't nearly so prominent in profiles the benchmark introduced in #507 which should be pretty similar to the existing "large streams" benchmark, so maybe criterion is confusing things somehow. The performance benefit seems to stand, however, perhaps in part due to fewer calls into the reactor machinery.