deps: bump socket2 from 0.4.7 to 0.5.1

[dependabot]

Bumps socket2 from 0.4.7 to 0.5.1.

Changelog

Sourced from socket2's changelog.

0.5.1

Added

• Type::cloexec for Redox and Solaris (rust-lang/socket2#398).
• Generate documentation for more targets on docs.rs (rust-lang/socket2#398).

Fixed

• Generatation of documentation on docs.rs (rust-lang/socket2#398).

0.5.0

Changed

• BREAKING SockAddr::init is renamed to try_init to indicate it can fail (rust-lang/socket2#328).
• BREAKING Remove the returned Result from SockAddr::vsock, it can't fail (rust-lang/socket2#328).
• BREAKING From<S> is now implemented using the I/O traits AsFd and AsRawSocket (rust-lang/socket2#325):
• BREAKING renamed SockAddr::vsock_addr SockAddr::as_vsock_addr to match the IPv4 and IPv6 methods (rust-lang/socket2#334).
• Redox now works on a stable compiler (rust-lang/socket2#326).
• Remove copy from From<SocketAddrV{4,6}> implementation for SockAddr (rust-lang/socket2#335).
• Marked function as constant where possible.
• Updated to Rust edition 2021 (rust-lang/socket2#393).

Added

• Links to OS documentation to a lot of methods (rust-lang/socket2#319).
• I/O-safety traits (rust-lang/socket2#325):
  • AsFd for Socket (Unix only).
  • From<OwnedFd> for Socket (Unix only).
  • From<Socket> for OwnedFd (Unix only).
  • AsSocket for Socket (Windows only).
  • From<OwnedSocket> for Socket (Windows only).
  • From<Socket> for OwnedSocket (Windows only).
• Unix socket support on Windows (rust-lang/socket2#249).

... (truncated)

Commits

• See full diff in compare view

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

> **Note** > Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

[mxinden]

Upgrade needs additional changes in libp2p-tcp and libp2p-mdns.

[thomaseizinger]

I bumped MSRV for mdns and tcp. I do think we should consider that a breaking change so I am adding this to the v0.52 milestone.

[mxinden]

What is the benefit of the v0.52 milestone? Would we go through all changes of the milestone before the release, figure out the breaking changes, which crates they touch, and bump the versions accordingly?

How is that different to the ! in the conventional commit title?

I would prefer bumping the versions of libp2p-tcp and libp2p-mdns in this pull request directly. I am happy to do it. Let's discuss this first though.

[thomaseizinger]

I started a discussion about this here: #3532

[thomaseizinger]

How is that different to the ! in the conventional commit title?

It is unfortunately effectively useless for our workspace because a single commit (from squashing a PR) might easily touch multiple crates and you thus lose the correlation of which crate touched by the commit the breaking change refers to.

Would we go through all changes of the milestone before the release, figure out the breaking changes, which crates they touch, and bump the versions accordingly?

Only breaking changes go into that milestone because 0.52 is the next "breaking change" release from 0.51.X's perspective.

I would prefer bumping the versions of libp2p-tcp and libp2p-mdns in this pull request directly. I am happy to do it. Let's discuss this first though.

The problem with this is that we give up on shipping features without breaking changes. Merging one breaking change attracts more breaking changes because "the damage has already been done". This way, we pile up features and features in master and only eventually cut a release.

If we hold off on merging breaking changes, I'd hope that we:

a) Release more often because master is by default not breaking
b) Are more hesitant in making breaking changes because they take longer to merge
c) Can plan and pool together breaking changes with more thought thus effectively making fewer of them

[thomaseizinger]

For example, I'd want to us to ship #3386 fairly soon without and finalize the whole connection management topic (with a few more PRs coming) without doing another breaking change.

[dependabot]

A newer version of socket2 exists, but since this PR has been edited by someone other than Dependabot I haven't updated it. You'll get a PR for the updated version as normal once this PR is merged.

[thomaseizinger]

@dependabot recreate

[dependabot]

Superseded by #3873.