feat(quinn-udp): support both windows-sys v0.52 and v0.59

[mxinden]

quinn-udp depends on the windows-sys crate, more specifically windows_sys::Win32::Networking::WinSock:

quinn/quinn-udp/src/cmsg/windows.rs

Line 6 in a5d9bd1

use windows_sys::Win32::Networking::WinSock;

quinn/quinn-udp/src/windows.rs

Line 13 in a5d9bd1

use windows_sys::Win32::Networking::WinSock;

Previously quinn-udp was using windows-sys v0.52. #1960 updated quinn-udp to v0.59. Note that windows-sys went straight from v0.52 to v0.59. There are no versions in between.

quinn-udp does not depend on any windows-sys v0.59 features. In other words, it can support both windows-sys v0.52 and v0.59.

https://github.com/microsoft/windows-rs/releases/tag/0.59.0

This commit allows downstream users of quinn-udp to explicitly use quinn-udp with windows-sys v0.52.

For other users not explicitly demanding windows-sys v0.52, cargo will choose windows-sys v0.59:

It also attempts to use the greatest version currently available within that compatibility range.

https://doc.rust-lang.org/cargo/reference/resolver.html#semver-compatibility

---

Additional context:

• Mozilla tries to use a single version of a crate only.
• Currently 13 crates used to build Firefox use windows-sys v0.52.0.
• Updating each crate to windows-sys v0.59 is a large undertaking. E.g. socket2 exposes windows-sys in its public interface, thus upgrading to windows-sys v0.59 is a breaking change, see Bumping windows-sys is a Semver breaking change rust-lang/socket2#526.
• In the meantime, quinn-udp supporting windows-sys v0.52 AND v0.59 allows Firefox to use quinn-udp v0.5.5 today already and thus make use of e.g. Revert "Implement fallback for sendmmsg and recvmmsg" #1966.

Note that the ask is to support windows-sys v0.52 only while quinn-udp does not depend on any windows-sys features >= v0.59. As soon as quinn-udp needs any windows-sys >=v0.59 features, it should naturally drop windows-sys v0.52 support.

[djc]

Seems reasonable to me. I still also like the solution of pregenerating bindings using windows-bindgen, which would sidestep these issues.

[Ralith]

Theoretically significant risk of bitrot here without CI coverage, but I don't expect our use of windows-sys will change meaningfully for the foreseeable future.

[mxinden]

Thank you for the very quick help here @djc and @Ralith!

I still also like the solution of pregenerating bindings using windows-bindgen, which would sidestep these issues.

I don't have enough experience with windows-bindgen to say whether it is worth the additional complexity.

Theoretically significant risk of bitrot here without CI coverage, but I don't expect our use of windows-sys will change meaningfully for the foreseeable future.

Agreed!

(At least, once in Firefox, the latest release will be tested a couple million times per day :P )