Bumping `windows-sys` is a Semver breaking change

[abonander]

• socket2 0.5.5 depends on windows-sys 0.48
• socket2 0.5.6, 0.5.7 depend on windows-sys 0.52

This is a breaking change because windows_sys::Win32::Networking::WinSock::SOCKADDR_STORAGE is reexported as the sockaddr_storage type, making it a part of the public API: https://github.com/rust-lang/socket2/blob/master/src/sys/windows.rs#L63

This can lead to build failures from a seemingly innocuous cargo update:

error[E0308]: mismatched types
    --> ffi\src\external_net.rs:44:24
     |
44   |     sockaddr_out.write(sockaddr.as_storage());
     |                  ----- ^^^^^^^^^^^^^^^^^^^^^ expected `SOCKADDR_STORAGE`, found a different `SOCKADDR_STORAGE`
     |                  |
     |                  arguments to this method are incorrect
     |
     = note: `SOCKADDR_STORAGE` and `SOCKADDR_STORAGE` have similar names, but are actually distinct types
note: `SOCKADDR_STORAGE` is defined in crate `windows_sys`
    --> C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\windows-sys-0.52.0\src\Windows\Win32\Networking\WinSock\mod.rs:5109:1
     |
5109 | pub struct SOCKADDR_STORAGE {
     | ^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: `SOCKADDR_STORAGE` is defined in crate `windows_sys`
    --> C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\windows-sys-0.48.0\src\Windows\Win32\Networking\WinSock\mod.rs:6988:1
     |
6988 | pub struct SOCKADDR_STORAGE {
     | ^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: method defined here
    --> /rustc/051478957371ee0084a7c0913941d2a8c4757bb9\library\core\src\ptr\mut_ptr.rs:1586:25

0.5.6 should have been released as 0.6.0.

Resolution

• If this reexport is semver-exempt, it needs to be clarified in the documentation. Users need to be advised to pin the socket2 version.
• If this reexport is not semver-exempt, the windows-sys dependency should be marked with a warning in Cargo.toml not to bump it in a patch release.

We've already worked around the breakage, so I don't really care what happens to the released version.

[Thomasdezeeuw]

Yes, this is totally correct.

We have a problem where we want to be able to extract the underlying raw/C types, but that means we depend on external crates in our API. For libc this is mostly not a problem because it's stable-ish -- the update to v1 will have this problem though. Windows-sys is worse because they release way too many version for such a low-level crate.

We can drop all types from external types from our API, but we want to keep the ability to get the underlying raw/C types. This problem will have to be solved. I don't have a solution for now.