udp: add support for ECN, local addrs, GSO, and GRO on Windows

[stormshield-damiend]

This adds support for ECN on Windows using WSARecvMsg() and WSASendMsg() from WinSock API.

This solves #765.

Some points need to be discussed or done :

• WSARecvMSG() cannot be accessed directly, we need to retrieve its function pointer using a dedicated call to WSAIoctl(). This detection may fail on old versions of windows (it seems to have been added as an extension in Windows XP). Do we keep the old API as a fallback (as currently done in the draft PR) ?
• If we keep the fallback API, do we still send ECN if we cannot receive them ?
• The previous detection is also done at every creation of a socket. Should this be done once on a dummy UDP socket in a lazy way (using OnceCell or OnceLock for example) ?
• All unsafe code block must be checked and have a # Safety : documentation
• wsa_cmsg.rs must be reviewed carefully
• see if we could merge cmsg.rs and wsa_cmsg.rs
• dual stack test must be done

Some possible long term tasks or benefits :

• We could try to merge cmsg and wsa_cmsg into socket2, as at the moment, there is no API to read or write socket control messages
• Using the new API gives us access to some other control messages / features, for example we could use URO

Feel free to comment on this draft.

[Ralith]

Thanks for digging into this!

[djc]

I do think this should not be just one commit. I'd suggest at least some commits like this:

• Move cmsg.rs to cmsg/mod.rs
• Further splitting of cmsg into multiple modules without any other changes
• Change cmsg to new structure on the Unix side that can accomodate the changes for Windows
• Add changes for Windows

Instead of depending on once_cell, could we use OnceLock instead? We'd have to bump the MSRV a bunch...

[stormshield-damiend]

I do think this should not be just one commit. I'd suggest at least some commits like this:

* Move `cmsg.rs` to `cmsg/mod.rs`

Ok i can do that

* Further splitting of `cmsg` into multiple modules without any other changes

Something like encoder.rs / decoder.rs / iterator.rs ?

* Change `cmsg` to new structure on the Unix side that can accomodate the changes for Windows

Sure i can do that

* Add changes for Windows

In one commit ?

Instead of depending on once_cell, could we use OnceLock instead? We'd have to bump the MSRV a bunch...

Yes i can do that, but this is your and @Ralith calls.

[djc]

I do think this should not be just one commit. I'd suggest at least some commits like this:

* Move `cmsg.rs` to `cmsg/mod.rs`

Ok i can do that

* Further splitting of `cmsg` into multiple modules without any other changes

Something like encoder.rs / decoder.rs / iterator.rs ?

Sorry, I meant splitting along the lines of the split you have now (so in this commit, just splitting unix.rs out of mod.rs).

* Change `cmsg` to new structure on the Unix side that can accomodate the changes for Windows

Sure i can do that

* Add changes for Windows

In one commit?

If you think there are multiple stages that can each compile and pass tests, that might be nice?

Instead of depending on once_cell, could we use OnceLock instead? We'd have to bump the MSRV a bunch...

Yes i can do that, but this is your and @Ralith calls.

Let's see what @Ralith thinks.

[stormshield-damiend]

I have taken into account @djc remarks. I still need to add Safety comments where needed.

[djc]

Looking pretty good!

[Ralith]

Instead of depending on once_cell, could we use OnceLock instead? We'd have to bump the MSRV a bunch...

Our rule of thumb is 6 months, right? 1.70 is just about there, so I'm fine with it. Tokio's still on 1.63, but probably they just haven't had any need to change, and there's no sense letting that hold us back arbitrarily. It's also a really trivial update, though, so I'm also happy to judge it non-blocking and handle it personally in a followup if @stormshield-damiend wants to stay focused.

[stormshield-damiend]

Instead of depending on once_cell, could we use OnceLock instead? We'd have to bump the MSRV a bunch...

Our rule of thumb is 6 months, right? 1.70 is just about there, so I'm fine with it. Tokio's still on 1.63, but probably they just haven't had any need to change, and there's no sense letting that hold us back arbitrarily. It's also a really trivial update, though, so I'm also happy to judge it non-blocking and handle it personally in a followup if @stormshield-damiend wants to stay focused.

Fine with me, lets keep the once_cell dependency and remove it later.

[Ralith]

Added GSO and GRO support while I was at it. I wasn't able to observe GRO working in loopback tests, but at least it isn't hurting.

Bulk benchmark on Windows has ~doubled performance with GSO.

[djc]

(Not a full review, just reviewing for semver incompatibility changes -- I didn't spot any.)

[Ralith]

Thanks for taking care of this! This is a huge and long overdue improvement to our performance and reliability on Windows.