[deployer + documentation] Add deployer and docs support for faster intial hub setups

[GeorgianaElena]

Rendered at https://2i2c-pilot-hubs--3956.org.readthedocs.build/hub-deployment-guide/runbooks/phase3/

I've been working on this today. Unfortuantelly ran out of time to give one final review and fix the super obvious issues.

What does this PR do

It adds three more deployer commands

that are meant to assist the engineeres when deploying a new hub. To be less intrusive and less prone to mistakes and magical powers, the commands will just output the relevant configuration that should be added in various hub yaml files, and lets the engineer do the final checkout and copy-paste it in the relevant files.

the commands are:

Usage: deployer generate hub-asset [OPTIONS] COMMAND [ARGS]...                                                                                
                                                                                                                                               
 Generate various hub assets to make deploying a new hub easier                                                                                
                                                                                                                                               
╭─ Options ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ --help          Show this message and exit.                                                                                                 │
╰─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
╭─ Commands ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ cluster-entry       Outputs the relevant cluster.yaml hub entry that the engineer can then manually copy-paste into the relevant            │
│                     cluster.yaml file.                                                                                                      │
│ common-values-file  Outputs the relevant common.values.yaml hub file contents that the engineer can then manually copy-paste into the       │
│                     relevant values.yaml file.                                                                                              │
│ main-values-file    Outputs the relevant hub.values.yaml hub file contents that the engineer can then manually copy-paste into the relevant │
│                     values.yaml file.                                                                                                       │
╰─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

It documents the Phase 3.1 of the new hub deployment process

I will be trying the docs here for the new kitware hub and adjust it whenever it needs to be adjusted.

Motivation

If we want to deploy new hubs super fast, then we need automation to help up find relevant configuration that needs to be hub-tailored as well as step-by-step documentation.

This is an iteration of this effort.

[sgibson91]

Not totally relevant to this PR but...

There's a comment a little further up that states "Include changes to the deployer script's folder, but exclude some parts" - it would be nice to have some more detail on what parts we do want to include and what parts we don't, and why. Because my initial reaction seeing this change was "At what point do we just list !deployer/**?" and I'm still in the camp that the deployer should be a separate repo tbh.

[consideRatio]

Wiee nice, looks great! I wrote some comments but nothing is blocking so resolve what you think makes sense and go for it.

[consideRatio]

Suggested change

	#If the hub is a daskhub, please indent everything under a basehub key
	#basehub:
	{% if hub_type == "daskhub" %}
	# FIXME: indent everything under this basehub key
	basehub:
	{% endif %}

This should cause a validation failure if its not done as well I think, as the basehub: line sets basehub to null, making all other defaults nulled.

[GeorgianaElena]

Will need to make the command also accept hub_type as it doesn't at the moment and I'm not sure we should, since it's a super small change to make.

Also, since this command outputs the config to stdout, we'll be compelled to verify the config when we paste it in the file and do the indent manually anyway and the indentation will still need to be done manually.

I'd say to leave it like this for now and if it proves to be an error generator, we'll introduce hub_type and the validation failure. WDYT?

[GeorgianaElena]

Thank you for reviewing this @consideRatio and @sgibson91 🚀

[github-actions]

🎉🎉🎉🎉

Monitor the deployment of the hubs here 👉 https://github.com/2i2c-org/infrastructure/actions/runs/8739232628