Introduce Bootstrap secrets

[mhjacks]

"Bootstrap" secrets are directly injected into a cluster to make the rest of the pattern work; examples include secrets necessary for using CSI drivers or secrets that ArgoCD needs to access pattern material. There has not been a clear mechanism for doing this previously.

This PR introduces a workflow that introduces a stage at the beginning of a pattern install (immediately after the creation of the pattern CR) that looks for bootstrap secrets and attempts to install them (failing if it finds them and can't).

The process looks for bootstrap secrets outside of the git repository only, using the suffix "-boostrap", so it could find and process ~/values-secret-multicloud-gitops-boostrap.yaml or ~/values-secret-boostrap.yaml, for example.

It will also be possible to install them as a separate step using the load_secrets_bootstrap.yml playbook.

This PR fixes an issue with discovering pattern settings and allows the display_secrets_info playbook to run as well.

A followup PR will add appropriate targets to Makefile-common.

[mbaldessari]

I like the concept per se a lot! Two drive-by thoughts:

1. If we want this even for secrets that are needed for argo to clone repos, we should probably make sure we cover https://validatedpatterns.io/blog/2023-12-20-private-repos/ (and make sure drew's upcoming PR will be adapted as well add gitlab https private repo section docs#679)
2. What if instead of a separate file altogether we use the same file, but just extend it with a bootstrap section (with the secret injected in the cluster before the install). This way we have the advantage of having a single file to protect and the cognitive load is much smaller for a user.

[mhjacks]

1. Yes, I can include details of how to plumb secret repos in the blog post. I'm working on that now.
2. I thought about that, but teasing apart the use cases gets really weird. Since in almost all cases the secret set will be disjoint, we have to provide a mechanism to ignore/include, and the existing semantics. Let me play with that a bit

[mhjacks]

Marking as WIP again while exploring options for only using the single secrets file

[mhjacks]

Removed WIP again. Consolidated logic to add a bootstrap: key to the secret, which can be absent, false, true, or "only". absent/false means the secret is skipped during the bootstrap phase. "true" means it is included in the bootstrap phase and the regular loading phase; "only" means it is included in bootstrap and excluded from the main secrets loading phase.

[mbaldessari]

I think it would make more sense to just have a separate "bootstrap_secrets" section and drop the bootstrap field entirely. If for whatever odd reason a user needs the same secret in both k8s and vault he can just duplicate them in both sections. Also code wise this is a lot simpler to reason about (especially for the UI as well). You also have less risk of breaking things, because the load_secrets bit can stay mostly unchanged and you just need to do some validation on the bootstrap secrets and then create them as k8s secrets normally. And it is a bit simpler for the user to reason about as well.

What would be nice is to spell out somewhere the exact use cases for all this and how this will work exactly and why they should/must be bootstrap secrets. Right now we have:

1. Private git repos
2. CSI secrets to get storage
3. Anything else?

So today for case 1. we pass this to a pattern CR:

spec:
  clusterGroupName: hub
  gitSpec:
    targetRepo: git@github.com:mbaldessari/mcg-private.git
    targetRevision: private-repo
    tokenSecret: private-repo
    tokenSecretNamespace: patterns-operator

I assume that we will need to add docs to add an example to the bootstrap_secrets section for the above private-repo secret. It'd be nice to have some more concrete examples somewhere. So the example could be:

bootstrap_secrets:
  - name: private-repo
    targetNamespaces:
      - patterns-operator
    fields:
      - name: type
        value: git
      - name: sshPrivateKey
        value: -----BEGIN OPENSSH PRIVATE KEY-----
      - name: url
        value: git@github.com:mbaldessari/mcg-private.git

It will also need a label/annotations as well (no matter how we do that). I do wonder if we shouldn't come up with a more user-friendly to define the non secret bits of this (e.g. type, url)?

[mhjacks]

I am opposed to creating a separate section of the file for this. I think in enough cases, people will also want to inject these secrets into their designated secret store, and duplicating them (by handling this with separate sections) is an invitation for the declarations to drift. Labels and annotations are already supported for the none injector.