Clamp effective maximum MTU using the underlying interface limits

[Ralith]

This is made straightforward by Mozilla's shiny new mtu crate. As with MTUD support, this should be layered on top of, rather than taking the place of, the user's configuration, passed down as an additional constraint on the side from the quinn layer.

[nadongjun]

@Ralith I’d like to take this on—please assign it to me if possible. Thanks!

[Ralith]

Thanks for having a look! Feel free to reach out if you have any questions.

[Ralith]

Some complexities to be wary of:

• quinn-proto may generate transmits to multiple addresses, even within a single connection. Transmits to different addresses may be interleaved. There isn't any mechanism to know, in advance, where the next transmit will go.
• We probably shouldn't poll this information from the OS every time we transmit.
• The value reported to the OS may change over time. It may or may not be important to react to that automatically.

[nadongjun]

@Ralith Thank you for the detailed explanation. I’ll reach out if I have any questions as I progress.

[larseggert]

• We probably shouldn't poll this information from the OS every time we transmit.

Definitely not. Getting this info via routing sockets is not cheap (many syscalls).