std::net: clamp multicast ttl value to u8 max.

[devnexen]

on some platforms the underlying type is c_uchar,
values above 255 would silently truncate.

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @ChrisDenton, libs
• @ChrisDenton, libs expanded to 8 candidates
• Random selection from Mark-Simulacrum, joboet

[Mark-Simulacrum]

Nominating for libs-api to decide if we want to truncate in std or not. AFAICT, the choice of u32 for the API is historical (I see it's been defined as such since the RFC proposing these, rust-lang/rfcs#1461).

The underlying IPv4 packet only has space for u8 (255) TTL, which is what constrains this under the hood. I think the primary alternative is to panic or return an Err in userspace. Linux returns EINVAL on values > 255 (https://github.com/torvalds/linux/blob/7df48e36313029e4c0907b2023905dd7213fd678/net/ipv4/ip_sockglue.c#L1051-L1052) so we'd technically be hiding an error here for at least Linux.

Maybe the right thing is to change the as-cast into .try_into()? or so?

[nia-e]

It seems like on most platforms including Linux, giving a TTL over 255 will return EINVAL - so in the @rust-lang/libs-api meeting, we decided that we'd rather just error here instead of clamping. A similar PR would be welcome for other cases where we set TTL, because this only addresses the multicast case