autohttps: traefik's config now configurable and in YAML

[consideRatio]

PR summary

YAML instead of TOML

The autohttps deployment run Traefik, and we are in this PR switching from configuring it with YAML instead of TOML, for two reasons.

1. It avoids introducing TOML as yet another markup language to understand to maintain this repo.
2. Yaml is supported better by helm (fromYaml exists, but not fromToml), and I want to use this.

Extensible configuration in a sustainable way

The configuration options proxy.traefik.extraStaticConfig and .extraDynamicConfig are added to allow a chart user to add generic configuration into Traefik's config. By doing so, we setup for a more sustainable experience that doesn't require the Chart maintainers to add more and more templating options, while also allowing the chart user to configure whatever is of relevance.

The end goal of this work is to help for example BinderHub hook into our automatic HTTPS setup by adding endpoints that traefik can route to to get HTTPS through Z2JH's setup.

Implementation tricks explained

I've opted to create defined templates, one to render each Traefik configuration file. This allow me to take it and pass the rendered templates to fromYaml that transforms it back to an object as compared to big string of YAML. Following that, we can merge this object with .extra<Static|Dynamic>Config.

By doing this, we get to inject content from for example proxy.https.hosts into the configuration, and also allow the chart user to then do any change it likes.

[consideRatio]

(removed to avoid clutter)

[consideRatio]

@yuvipanda and @GeorgianaElena, I make a trick I do in this PR to configure Traefik in a way that hopefully avoids a very common problem for Helm charts - that we end up adding more and more and more templating in order to allow the user to configure more and more.

The trick allow us to take a rendered Helm template and let the user merge any additional configuration into it!

1. Render a template inside a defined function.
2. Cast the rendered template (string) into an object using the fromYaml function.
3. Merge the user provided configuration into the object.
4. Render the object into a string using the toYaml function.
5. Write the rendered string to a ConfigMap resource, so it can become a file such as traefik.yaml mounted in a container.

By this approach, I hope we can avoid a common Helm chart problem described in this video.

What do you think?

[GeorgianaElena]

Great work @consideRatio ❤️

I love the idea of letting users add their own custom config and that the static and dynamic config are separated into their own files. This seems less scary than having one big file and it's very nice that you don't need to restart whenever you modify dynamic config pieces.

LGTM 🎉

[consideRatio]

After having read more about HSTS, I also added the option to specify the preload directive of the STS header. For more info, read at https://hstspreload.org/. I followed the RFC specification and didn't enable this by default according to their recommendation.

[consideRatio]

I think this is ready for merge now!

@jcrist as a developer of the dask-gateway helm chart, I want to suggest usage of this pattern to configure your executables. Helm has an issue, and this pattern avoids it to a large degree.