Add a flux kustomisation for sylvactl bootstrap

What does this MR do and why?

We intent to manage the installation of flux controllers in sylvactl bootstrap command (see sylva-projects/sylva-elements/sylvactl!352 (merged)). For that purpose, we have to embed manifests in golang package.

In order to ensure that these manifests remain in sync with sylva-core (in terms of versions and configuration), we should reuse the same kustomisation to build these manifests.

These manifests need anyway some adaptations as all the kustomizations are not relevant in bootstrap context: we don't have persistant storage in that context, neither certificate authority, but we use a configmap to pass proxy environment values instead of sustitutions.

For that purpose, current kustomizations have to be re-organized, as current base kustomization used in management cluster can't be re-used in bootstrap context.

Here is the resulting layout:

├── base                            # Common base for bootstrap & in-cluster
│   ├── kustomization.yaml
│   └── netpol.yaml 
├── bootstrap                       # Consumed by sylvactl bootstrap
│   └── kustomization.yaml
├── components
│   ├── bootstrap                   # Used by bootstrap & offline 
│   │   └── kustomization.yaml
│   ├── common                      # Used in all contexts (can't be in base, since offline does not use base)
│   │   └── kustomization.yaml    
│   ├── configmap-proxy-env-vars    # Used by bootstrap
│   │   └── kustomization.yaml
│   ├── extra-ca                    # Used by in-cluster
│   │   ├── certs.yaml
│   │   └── kustomization.yaml
│   ├── extra-config                # Used by in-cluster
│   │   └── kustomization.yaml
│   ├── persistant-sources          # Used by in-cluster
│   │   ├── kustomization.yaml
│   │   └── pvc.yaml
│   └── substituted-proxy-env-vars  # Used by offline & in-cluster
│       └── kustomization.yaml
├── in-cluster                      # Consumed by flux-system kustomization
│   └── kustomization.yaml
└── offline                         # Consumed by bootstrap.sh 
    ├── kustomization.yaml
    └── manifests.yaml

Well be able to simplify it once we'll get rid of the offline bootstrap option, but in the meantime we've to keep using components.

Related reference(s)

Relates to sylva-projects/sylva-elements/sylvactl!352 (merged)

CI configuration

Below you can choose test deployment variants to run in this MR's CI.

Click to open to CI configuration

Legend:

Icon	Meaning	Available values
☁️	Infra Provider	capd, capo, capm3
🚀	Bootstrap Provider	kubeadm (alias kadm), rke2
🐧	Node OS	ubuntu, suse
🛠️	Deployment Options	light-deploy, dev-sources, ha, misc, maxsurge-0, logging, no-logging
🎬	Pipeline Scenarios	Available scenario list and description

• 🎬 preview ☁️ capd 🚀 kadm 🐧 ubuntu

• 🎬 preview ☁️ capo 🚀 rke2 🐧 suse

• 🎬 preview ☁️ capm3 🚀 rke2 🐧 ubuntu

• ☁️ capd 🚀 kadm 🛠️ light-deploy 🐧 ubuntu

• ☁️ capd 🚀 rke2 🛠️ light-deploy 🐧 suse

• ☁️ capo 🚀 rke2 🐧 suse

• ☁️ capo 🚀 kadm 🐧 ubuntu

• ☁️ capo 🚀 rke2 🎬 rolling-update 🛠️ ha 🐧 ubuntu

• ☁️ capo 🚀 kadm 🎬 wkld-k8s-upgrade 🐧 ubuntu

• ☁️ capo 🚀 rke2 🎬 rolling-update-no-wkld 🛠️ ha 🐧 suse

• ☁️ capo 🚀 rke2 🎬 sylva-upgrade-from-1.3.x 🛠️ ha 🐧 ubuntu

• ☁️ capo 🚀 rke2 🎬 sylva-upgrade-from-1.3.x 🛠️ ha,misc 🐧 ubuntu

• ☁️ capo 🚀 rke2 🛠️ ha,misc 🐧 ubuntu

• ☁️ capm3 🚀 rke2 🐧 suse

• ☁️ capm3 🚀 kadm 🐧 ubuntu

• ☁️ capm3 🚀 kadm 🎬 rolling-update-no-wkld 🛠️ ha,misc 🐧 ubuntu

• ☁️ capm3 🚀 rke2 🎬 wkld-k8s-upgrade 🛠️ ha 🐧 suse

• ☁️ capm3 🚀 kadm 🎬 rolling-update 🛠️ ha 🐧 ubuntu

• ☁️ capm3 🚀 rke2 🎬 sylva-upgrade-from-1.3.x 🛠️ ha 🐧 suse

• ☁️ capm3 🚀 rke2 🛠️ misc,ha 🐧 suse

• ☁️ capm3 🚀 rke2 🎬 sylva-upgrade-from-1.3.x 🛠️ ha,misc 🐧 suse

• ☁️ capm3 🚀 kadm 🎬 rolling-update 🛠️ ha 🐧 suse

• ☁️ capm3 🚀 ck8s 🎬 no-wkld 🛠️ light-deploy 🐧 ubuntu

Global config for deployment pipelines

• autorun pipelines
• allow failure on pipelines
• record sylvactl events

Notes:

• Enabling autorun will make deployment pipelines to be run automatically without human interaction
• Disabling allow failure will make deployment pipelines mandatory for pipeline success.
• if both autorun and allow failure are disabled, deployment pipelines will need manual triggering but will be blocking the pipeline

Be aware: after configuration change, pipeline is not triggered automatically. Please run it manually (by clicking the run pipeline button in Pipelines tab) or push new code.