Simplified integration with namespace local JupyterHub Helm charts

[consideRatio]

Summary

Closes #473. The idea is to enable users installing both the dask-gateway chart and jupyterhub chart to not provide any api-token credential for dask-gateway/juyterhub to trust each other, but instead rely on a generated api-token persisted in a k8s Secret.

The implementation plan in #473 was the following:

Implementation idea

1. Allow a k8s Secret name and key be configurable to mount the JupyterHub API token from a custom k8s Secret with a given key.
2. Make the creation of the dask-gateway managed k8s Secret be conditional of not providing a custom k8s Secret name / key.
3. Update the values schema with these settings

This PR follows that plan quite well, but provides a default for the k8s Secret name and Key config and relies on them by default unless the previously required apiToken is specified. This PR also updates the documentation under the topic of installing the dask-gateway helm chart and autenticating against a JupyterHub Helm chart installation.

Added chart config in values.yaml

gateway:
  auth:
    jupyterhub:
      # The JupyterHub Helm chart will automatically generate a token for a
      # registered service. If you don't specify an apiToken explicitly as
      # required in dask-gateway version <=2022.6.1, the dask-gateway Helm chart
      # will try to look for a token from a k8s Secret created by the JupyterHub
      # Helm chart in the same namespace. A failure to find this k8s Secret and
      # key will cause a MountFailure for when the api-dask-gateway pod is
      # starting.
      apiTokenFromSecretName: hub
      apiTokenFromSecretKey: hub.services.dask-gateway.apiToken

The schema file is also updated to reflect this new configuration.

Successfully tested

I've tested this on the hub.jupytearth.org deployment of a dask-gateway deployed next to a jupyterhub.

How dask/helm-chart's daskhub would adjust with this

Steps relating to generating and configuring an api token could be simplied. This would be an example of the configuration to have, without secret credentials involved.

jupyterhub:
  hub:
    services:
      dask-gateway:
        display: false

dask-gateway:
  gateway:
    auth:
      type: jupyterhub

[TomAugspurger]

Very cool @consideRatio!

One quick question: do you worry at all about upgrades to existing deployments? I suspect things will be just fine, since providing your own tokens continues to be an option.

[consideRatio]

One quick question: do you worry at all about upgrades to existing deployments? I suspect things will be just fine, since providing your own tokens continues to be an option.

Exactly, previously everyone has been forced to provide a token - so they should all be fine as this will only impact people not providing a token.

Thank you for looking at this PR @TomAugspurger!!!

[TomAugspurger]

Great, thanks. Feel free to merge whenever you're ready!

[consideRatio]

Thanks! Going for it!