Multiple parts of healthcheck broken/bugged

I noticed that our perfectly working GitLab always reports as 'starting', and looked into the healthcheck functionality and found multiple (easily fixed, I would think) issues with it:

• /usr/local/sbin/healthcheck is generated with incorrect protocol
• --location is supplied to curl, which will incorrectly report a wrong result
• GITLAB_MONITORING_IP_WHITELIST defaults to 0.0.0.0/8, which is not a thing
• GitLab URL is generated as localhost instead of 127.0.0.1

/usr/local/sbin/healthcheck is generated with incorrect protocol: if you run what I would think is a pretty default configuration of GitLab running behind a load balancer/nginx proxy/traefik/whatever to deal with HTTPS: GITLAB_HTTPS=true and SSL_SELF_SIGNED=false. In this case, /usr/local/sbin/healthcheck must use http, not https, because the server running on localhost does not supply its own HTTPS and will not respond on port 443. The incorrect line for this seems to be https://github.com/sameersbn/docker-gitlab/blob/b101d29c59431d581a3c76246d91e993d0b5a2d5/assets/runtime/functions#L1792 where only one of the two flags is checked.

--location is supplied to curl, which will incorrectly report a wrong result: --location will make curl follow the redirect to the login page if GITLAB_MONITORING_IP_WHITELIST is not set/set incorrectly. The command will then report a HTTP code of 200, which means it got the login page. It does not correctly correspond to the return code of /-/liveness, other than also reporting an error if the login page itself happens to not work, which often corresponds to unhealthy status (but not always!). I can never see a use case where --location would actually be helpful: the only scenario in which it would improve things is if the healthcheck protocol was set incorrectly, in which case you wouldn't want to just gloss over the error and report a healthy status.

GITLAB_MONITORING_IP_WHITELIST defaults to 0.0.0.0/8, which is not a thing: it would cover IPs from 0.1.1.1 to 0.255.255.255, which don't exist and make no sense here. Possibly meant to be 0.0.0.0/0, which would also be bad - healthcheck has a restriction for a reason, disabling security by default is not a good policy. It's also possible that this is the intended result - matching nothing by default - but in that case something that doesn't look nearly identical to 'everything' should be chosen. Maybe 0.0.0.0/32 ?

GitLab URL is generated as localhost instead of 127.0.0.1: which at least on Podman will not resolve the same way as 127.0.0.1, which is on the healthcheck whitelist by default. If the URL was changed to ://127.0.0.1/-/liveness, the issue above about the incorrect GITLAB_MONITORING_IP_WHITELIST would no longer be relevant (it wouldn't be needed in the first place). This problem results from the existence of IPv6: when present, requests to localhost will/might take the IPv6 route and result of a 'client' IP of ::1 instead of 127.0.0.1.

Those all seem pretty trivial to fix, it probably took me more time to type up than to fix. @sachilles are you interested in a PR along what I wrote above ? Not sure how user contributions are seen here.