Switch from kube-lego to cert-manager

Addresses https://gitlab.com/charts/helm.gitlab.io/issues/206

There's a lot to unpack here. First some use cases:

1. Users that don't have anything pre-installed and want a fully TLS'd gitlab
2. Users that have nginx-ingress already installed
3. Users that have cert-manager already installed but don't already have an issuer configured
4. Users that have cert-manager already installed and already have an issuer configured

For case 1, there will have to be a 2-step process. Either a) Users do helm install cert-manager and then helm install gitlab (essentially moving them to use case #3 (closed)) or b) They do helm install gitlab --set certmanager.install=true globals.ingress.configure_certmanager=false and then helm upgrade --install gitlab --set certmanager.install=true --set globals.ingress.configure_certmanager=true This is due to Helm not being able to create CRDs and use CRDs in the same helm run because validation of the CRD fails (since it isn't installed yet). I don't generally like that, but assuming helm isn't going to have a fix in before k8s 1.9 becomes GKE default and kube-lego stands firm with not supporting k8s 1.9, it is probably a necessary evil. Installing nginx is just --set nginx.install=true.

For case 2, --set globals.ingress.enabled=true is enough to deploy the ingresses without deploying the controller. I've moved all the ingresses into their respective services which simplifies them quite a bit. You can also selectively override the global setting with things like --set registry.ingress.enabled=true/false. There is some future work to be able to customize the nginx ingress class (since users already using nginx-ingress controller will sometimes have customized class names).

For case 3 it is sufficient to do --set globals.ingress.configure_certmanager=true. You can also selectively override the global setting with things like --set registry.ingress.configure_certmanager=true/false but the global setting controls installation of an Issuer in the namespace. The settings for the issuer can be configured using certmanager.issuer.server (defaults to letsencrypt staging) and the required user setting for certmanager.issuer.email.

For case 4, all that is needed is annotations to configure the ingresses to use a pre-existing Issuer or ClusterIssuer. These users can use globals.ingress.annotations (or the corresponding individual service overrides) to set the documented cert-manager annotations for their pre-existing issuer.

I also added support for configuring external-dns since hostnames are dynamically generated. We use external-dns frequently and having that available makes dns configuration automatic so cert-manager Just Works™.

Also not sure why but redis didn't have any ports exposed in the deployment so I threw that in here too, thought I'm not entirely sure how anything worked without that?

This is all the config I needed to get to a mildly working front page:

global:
  hosts:
    domain: sprockets.click
certmanager:
  issuer:
    email: "corey@example.com"
gitlab:
  omnibus:
    trusted_proxies:
      - 100.64.0.0/10
      - 127.0.0.1/24

This is going to conflict with the work over in https://gitlab.com/charts/helm.gitlab.io/issues/204 but I needed separate ingresses for this too so I forged ahead to get something to look at. I kind of like the idea of the ingress resources living with the charts they correspond to as well.