Fixed dual stack port binding on same port

[rolfyone]

• Add shared dual-stack binding logic to avoid duplicate IPv4 wildcard binds when an IPv6 wildcard listener is configured on the same port.
• Apply the same-port dual-stack handling to libp2p TCP/QUIC listeners and discv5 UDP discovery listeners.
• Add regression coverage for listener generation, libp2p startup, and discovery UDP listen address construction.

Fixes #8659.

Fixed Issue(s)

Documentation

• I thought about documentation and added the doc-change-required label to this PR if updates are required.

Changelog

• I thought about adding a changelog entry, and added one if I deemed necessary.

---

Note

Medium Risk
Changes how P2P and discovery sockets are bound in dual-stack same-port configs; a documented tradeoff is that skipping the IPv4 bind may widen a specific IPv4 address to all interfaces when :: is used.

Overview
Fixes dual-stack setups where IPv4 and IPv6 were configured to use the same listen port, which could fail when both stacks tried to bind separately.

Introduces DualStackPortBindings.shouldListenOnAddress: when v4/v6 ports match and an IPv6 wildcard (::) is in the interface list, listeners are built for the IPv6 wildcard only so one dual-stack socket owns the port instead of a second IPv4 bind. That logic is wired into libp2p TCP/QUIC listen address/port generation and discv5 UDP discovery listen addresses.

Regression tests cover generated multiaddrs/ports, discovery listen construction, and libp2p startup without double TCP bind. Changelog notes dual-stack nodes can bind IPv4 and IPv6 on the same port.

^{Reviewed by Cursor Bugbot for commit 8ba4f9c. Bugbot is set up for automated code reviews on this repo. Configure here.}

[gfukushima]

lgtm, the bit in the PR description does concern me a little bit:

a documented tradeoff is that skipping the IPv4 bind may widen a specific IPv4 address to all interfaces when :: is used

might be worth exploring if make sense to tighten that since default for most users is IPV4

[Gasila5]

• Add shared dual-stack binding logic to avoid duplicate IPv4 wildcard binds when an IPv6 wildcard listener is configured on the same port.
• Apply the same-port dual-stack handling to libp2p TCP/QUIC listeners and discv5 UDP discovery listeners.
• Add regression coverage for listener generation, libp2p startup, and discovery UDP listen address construction.

Fixes #8659.

Fixed Issue(s)

Documentation

• I thought about documentation and added the doc-change-required label to this PR if updates are required.

Changelog

• I thought about adding a changelog entry, and added one if I deemed necessary.

---

[!NOTE]
Medium Risk
Changes how P2P and discovery sockets are bound in dual-stack same-port configs; a documented tradeoff is that skipping the IPv4 bind may widen a specific IPv4 address to all interfaces when :: is used.

Overview
Fixes dual-stack setups where IPv4 and IPv6 were configured to use the same listen port, which could fail when both stacks tried to bind separately.

Introduces DualStackPortBindings.shouldListenOnAddress: when v4/v6 ports match and an IPv6 wildcard (::) is in the interface list, listeners are built for the IPv6 wildcard only so one dual-stack socket owns the port instead of a second IPv4 bind. That logic is wired into libp2p TCP/QUIC listen address/port generation and discv5 UDP discovery listen addresses.

Regression tests cover generated multiaddrs/ports, discovery listen construction, and libp2p startup without double TCP bind. Changelog notes dual-stack nodes can bind IPv4 and IPv6 on the same port.

^{Reviewed by Cursor Bugbot for commit 8ba4f9c. Bugbot is set up for automated code reviews on this repo. Configure here.}

Gasila

[rolfyone]

lgtm, the bit in the PR description does concern me a little bit:

a documented tradeoff is that skipping the IPv4 bind may widen a specific IPv4 address to all interfaces when :: is used

might be worth exploring if make sense to tighten that since default for most users is IPV4

I checked this: the default path remains IPv4-only (0.0.0.0), so typical IPv4 users are not affected.

The scope-widening only applies when a user explicitly configures a specific IPv4 address plus IPv6 wildcard on the same port. With the current transport/JDK APIs we can’t preserve that exact narrow IPv4 scope while also sharing the port, so the alternative tightening would be to reject that specific contradictory config.

Given it previously failed to start and the behaviour is now documented, this should be fine.