fix(s2n-quic-transport): handle MaxMtu smaller than Base PLPMTU

[WesleyRosenblum]

Description of changes:

In #1737 we starting disabling MTU probing when the socket cannot support it by setting the MaxMtu for the endpoint to MaxMtu::MIN. MaxMtu::MIN is based on the smaller of the minimal IPv4 and IPv6 header lengths. The mtu::controller had a debug assertion that validated that the given MaxMtu is larger than a value that was dependent on if the peer socket address was IPv4 or IPv6. This means that an endpoint starting on a platform that cannot support MTU probing but can support IPv6 would fail this debug assertion, as the IPv6 header is larger. This change removes the debug assertion and instead just takes the max with the BASE_PLPMTU.

I've also removed some usage of the IPV6 feature that had previously been removed in #886

Testing:

Updated unit test, and tested locally on MacOS, which experiences this issue.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[ghost]

1200+8+40=1248 this is the min mtu for ipv6 quic but it should not be the default mtu.
all ipv6 platform support 1280mtu

from rfc9000
QUIC assumes a minimum IP packet size of at least 1280 bytes. This is the IPv6 minimum size [IPv6] and is also supported by most modern IPv4 networks. Assuming the minimum IP header size of 40 bytes for IPv6 and 20 bytes for IPv4 and a UDP header size of 8 bytes, this results in a maximum datagram size of 1232 bytes for IPv6 and 1252 bytes for IPv4. Thus, modern IPv4 and all IPv6 network paths are expected to be able to support QUIC.