Fix trusted proxies regression when hostname is specified

What does this MR do and why?

In GitLab Omnibus, specifying a trusted address in NGINX with a hostname is allowed, but was passed along to the Rails trusted proxies config. For example, a user could set:

nginx['real_ip_trusted_addresses'] = ['localhost']

This change would not only populate the NGINX config, but also update the GitLab Rails gitlab.yml.

Prior to !196981 (merged), hostnames were just ignored. In GitLab 18.3.0, however, this causes all requests to fail because IPAddr.new('localhost') raises an error, which is rescued but causes the trusted_proxies array to include a nil entry. With each incoming request, Puma then reports:

<NoMethodError: undefined method `include?' for nil:NilClass>
Error reached top of thread-pool: stack level too deep (SystemStackError)

This commit restores the behavior of filtering nil values.

The correct behavior may be for GitLab to resolve the IP addresses for these hostnames, but should likely be done periodically rather than at boot time given that IP addresses may change.

References

Relates to #565044 (closed)

How to set up and validate locally

1. In config/gitlab.yml:

    trusted_proxies:
      - localhost
      - 127.0.0.1

2. gdk restart rails-web

3. Make a request. You should now see 502s.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.