Add: Nested options

[rtmiz]

I was recently asked if we could support nested options with conditional rendering for our JupyterHub,

for instance choosing an Image and subsequently choosing a version of that image.

This PR is my working prototype of this behavior.

What works:

• Rendering of nested profile_option keys defined like so.
  This will make a Version drop-down menu appear when Default Image is selected.

profile_options:
  image:
    display_name: Image
    dynamic_image_building:
      enabled: True
    unlisted_choice:
      enabled: True
      display_name: "Custom image"
      validation_regex: "^.+:.+$"
      validation_message: "Must be a publicly available docker image, of form <image-name>:<tag>"
      display_name_in_choices: "Specify an existing docker image"
      description_in_choices: "Use a pre-existing docker image from a public docker registry (dockerhub, quay, etc)"
      kubespawner_override:
        image: "{value}"
    choices:
      default:
        display_name: Default Image
        description: "default python image"
        profile_options:
            version:
              display_name: Version
              choices:
                latest:
                  display_name: "V1"
                  description: "v1"
                  default: true
                  kubespawner_override:
                    image: quay.io/jupyter/minimal-notebook:v1
                old:
                  display_name: "V2"
                  description: "v2"
                  kubespawner_override:
                    image: quay.io/jupyter/minimal-notebook:v2

• Overriding the kubespawner_overrides from nested options depth > 0.
  Any kubespawner_overrides from lower levels are correctly applied when spawning a pod.

Caveats:

• KubeSpawner does not natively support nested options so the overrides have to be applied in a custom pre_spawn_hook
• because there is no native support, I had to make my own convention for nesting these options

Because the implementation technically works I wanted to create a PR for this and see if there is any interest in such a feature and if there is if there is any way we could implement this functionality smoother (potentially within KubeSpawner)

[batpad]

@wildintellect - I know you've been thinking of how to maintain image versions, etc. in the fancy-profiles UI.

This seems like a really interesting approach - it does introduce quite a lot of changes to the shape of the options, etc. but I also feel like this is the kind of thing that fancy profiles was built to support and I'd like to find a way to allow this kind of functionality and flexibility.

@wildintellect @sunu - can I ask the two of you to take a look here and see if it makes sense to you what this PR is trying to do and how useful we think this can be for our own setups, and we can take a call on how we can prioritize working with @rtmiz to get this merged.

(And thanks again for making this PR @rtmiz 🙏 - it's incredibly useful to see this as a PoC and I personally like the approach you've taken here.)

[wildintellect]

From a logic perspective, yes being able to get to old versions of images is important. Not much of an opinion on the technical approach used here, but I will note the config files will get enourmous, we sometimes do 4 versions a year (more if you count bug fix releases, but maybe that's nuanced and not necessary)

[rtmiz]

@wildintellect You could technically apply the profile_list within the extraConfig field and use python to format it dynamically (or just directly in jupyterhub_config.py). That would drastically save on line-space out of the box.

Alternatively we can work in a templating system, which infers values based on a given list of values directly from the .yaml