Fix docker goss test

[siladu]

Fixes docker.yml github workflow on self-hosted runner version 2.315.0 (docker 25.0.4+ 26.0.0?)

Since docker 26.0.0, IPv6 is used by default but our goss_wait test is expecting ports to be exposed on IPv4.
Note, this is a problem for amd64 as well as arm64.
Disabling IPv6 should work for all docker versions, at least while the runners are on various versions of docker.

Once all runners are on 26+ then we could probably change goss_wait.yml to:

# runtime docker tests for interfaces & ports
port:
  tcp6:30303:
    listening: true
    ip:
    - '::'
  udp6:30303:
    listening: true
    ip:
    - '::'
  tcp6:8545:
    listening: true
    ip:
    - '::'
  tcp6:8546:
    listening: true
    ip:
    - '::'
  tcp6:8547:
    listening: true
    ip:
    - '::'

and reenable IPv6

Fixes #6929

[siladu]

Explicit port mappings doesn't fix the issue

[siladu]

Seems to be introduced by this docker 26.0.0 feature...

https://docs.docker.com/engine/release-notes/26.0/#bug-fixes-and-enhancements-1

Always attempt to enable IPv6 on a container's loopback interface, and only include IPv6 in /etc/hosts if successful. moby/moby#47062

Note

By default, IPv6 will remain enabled on a container's loopback interface when the container is not connected to an IPv6-enabled network. For example, containers that are only connected to an IPv4-only network now have the ::1 address on their loopback interface.

To disable IPv6 in a container, use option --sysctl net.ipv6.conf.all.disable_ipv6=1 in the create or run command, or the equivalent sysctls option in the service configuration section of a Compose file.

If IPv6 is not available in a container because it has been explicitly disabled for the container, or the host's networking stack does not have IPv6 enabled (or for any other reason) the container's /etc/hosts file will not include IPv6 entries.

[jframe]

Seems like a sensible approach until all the runners can be updated

[siladu]

Seems like a sensible approach until all the runners can be updated

@jframe spoke to Josh - this is the preferred approach. Most users should remain on ipv4