Draft: Add Omnibus support for Let's Encrypt SSL

Relates https://gitlab.com/gitlab-org/quality/gitlab-environment-toolkit/-/issues/3

Mr looks to add Let's Encrypt support in GET for Omnibus setups. The process is involved and needs to happen in an exacting way for the vcalidation to be successful and for certificates to be correctly propogated. In details the MR works as follows:

• HAProxy is configured to have a TCP load balancer for SSL connections to Rails nodes (which can also be done by users for other load balancers)
• HAProxy is also configured with a special rule to listen for Let's Encrypt validation calls. The only way to handle this really is to point to the "primary" Rails node so this is what the rule does (can also be done by users for other load balancers)
• GitLab Rails setup is moved back to a primary / secondary setup. Now there's two distinct actions for Primary to do (migrations and SSL) the steps are reconfigured to always run on the primary node where conditionals are moved down to specific tests depending on Postgres node existing, etc...
• Let's Encrypt process is enabled specifically only on Primary when external_url has https in it
• nginx['redirect_http_to_https'] is enabled on the secondaries only. This is a weird one - When Let's Encrypt is enabled port 80 is opened for Let's Encrypt to hit as well as handle redirections. This isn't the case on secondaries so this setting is required for health checks etc... If this setting is enabled on the primary with LE it causes a 500 error.
• At runtime the Primary node does the LE process and downloads the certificates. Once down the certificates are copied over to NFS and then copied over to the secondaries
• Monitor node also needs to have certificates copied as it's Nginx server defaults to SSL like the others and HSTS will make the browsers always move the main daomin name to HTTPS by default.