Webservice: Implement IPv4 fallback if IPv6 is not available

What does this MR do?

Webservice: Implement IPv4 fallback if IPv6 is not available

To support binding IPv6 by default we need a fallback to IPv4 in case IPv6 is not usable. The goal is to enable IPv6 on every cluster/node that supports it, and to fall back to IPv4 otherwise.

The probe and address resolution live in a new PumaIPv6 helper module.

Related issues

Relates gitlab-org/charts/gitlab#6567 (closed)

Testing

1. Create a fresh GKE cluster with default settings, install master images and set BIND_IP6=true / gitlab.webservice.puma.bindIp6=true.

2. Confirm Puma fails booting with:

   {"component": "gitlab","subcomponent":"puma.stderr","time":"2026-07-16T14:22:58Z","message":"bundler: failed to load command: puma (/srv/gitlab/vendor/bundle/ruby/3.3.0/bin/puma)"}
   {"component": "gitlab","subcomponent":"puma.stderr","time":"2026-07-16T14:22:58Z","message":"/srv/gitlab/vendor/bundle/ruby/3.3.0/gems/puma-8.0.1/lib/puma/binder.rb:344:in `initialize': Cannot assign requested address - bind(2) for \"::1\" port 9293 (Errno::EADDRNOTAVAIL)"}

3. Upgrade the deployment to use the webservice image from this branch

4. Confirm the webservice starts, probes pass, and a fallsback to IPv4 has been performed

   kubectl logs -n gitlab gl-webservice-default-dc5776d74-m24q6 --container=webservice | grep -E "8080|9293"
   {"timestamp":"2026-07-16T14:29:23.342Z","pid":25,"message":"* Listening on http://0.0.0.0:8080"}
   {"component": "gitlab","subcomponent":"puma.stdout","timestamp":"2026-07-16T14:29:23.345Z","pid":25,"message":"* Starting control server on http://127.0.0.1:9293"}

Checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion

Required

• Merge Request Title, and Description are up to date, accurate, and descriptive
• MR targeting the appropriate branch
• MR has a green pipeline on GitLab.com
• When ready for review, MR is labeled "~workflow::ready for review" per the Distribution MR workflow

Expected (please provide an explanation if not completing)

• Test plan indicating conditions for success has been posted and passes
• Documentation created/updated
• Integration tests added to GitLab QA
• The impact any change in container size has should be evaluated
• New dependencies are managed with GitLab forked renovatebot