Use UDP segmentation offload when available

[Ralith]

Even with #491, the kernel part of sending is about a third of the large stream benchmark, maybe more if criterion overhead and receiver activity is excluded. ngtcp2 reports achieving 6.1Gbps using segmentation offload on recent Windows, and Linux acquired a similar feature as exercised in https://github.com/torvalds/linux/blob/master/tools/testing/selftests/net/udpgso.c and discussed in this paper. Care will need to be taken to preserve fallback support in environments where these are not available; on Linux this can be done with a runtime check, and on windows you can try to dynamically load the symbol from the relevant dll.

IIRC segmentation offload requires that all datagrams be destined to the same address, so this will require modifying the poll_transmit API to be batched. Similar measures can probably be applied to the receive path.

[Ralith]

Linux also recently grew support for zero-copy UDP send/recv, reporting dramatic speedups in microbenchmarks as a result: https://patchwork.ozlabs.org/patch/1006175/. It's described as only useful when combined with segmentation offload, as it needs to work in coarse units to be a performance benefit.

[Ralith]

The nginx folks report remarkable results from taking advantage of this: https://calendar.perfplanet.com/2019/accelerating-udp-packet-transmission-for-quic/

[Ralith]

https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency reports better-than-TLS+TCP performance

[Ralith]

This was implemented in #1054.