Feature: add alternative names and wildcard support to lagoon.yml

[shreddedbacon]

Problem

Currently Lagoon creates 1 ingress per route defined in the .lagoon.yml file. This also means 1 certificate per ingress. Over time, this can result in a large number of ingress and certificates being generated.

The aim of this PR is to allow routes to be defined with alternative names, this consolidates the routes into 1 ingress object, and also means that there will be 1 certificate generated for multiple domains using SAN certificates.

This is useful if you have a number of sub domains that you want to allocate to the same ingress object.

There is a limit on how many certificates that can be put into a SAN depending on the certificate generator. There appears to be no limit on the number of hosts that can be added to an ingress in kubernetes, so no limit is enforced in Lagoon.

Wildcard ingress are also supported in this. LetsEncrypt does not support http01 validation for wildcard certificates, because of this Lagoon will not support tls-acme generation for routes that are requested to be wildcard. If a user requests a wildcard ingress, they will have to define tls-acme: false in their .lagoon.yml too or the build will fail with an error.

It is also not possible to generate a wildcard route with alternative names. This will also cause the build to fail.

Configuring Alternative Names

environments:
  main:
    routes:
      - node:
          - example.com:
              alternativenames:
                - www.example.com
                - en.example.com

Configuring Wildcard

tls-acme has to be set to false as lets encrypt does not support wildcard http01 requests

environments:
  main:
    routes:
      - node:
          - example.com:
              tls-acme: false
              wildcard: true

[shreddedbacon]

Test infra project ben-nginx-example is configured with this build image and deployed a branch configured with 1 wildcard route, and 1 alternative names route.

Obviously due to the certificate limitation on wildcards, you will be presented an insecure warning.

The alternative names route does have a valid certificate and you can inspect it to see the certificate subject alternative names in the certificate.

I will note though, that for each alternative name, certmanager generated an individual acme challenge. So if users do use this feature, they need to ensure DNS is correct, I don't know how certmanager will behave if one of those challenges fails.