Draft: Use libvirt-metal in sylva-system ns and with standalone interfaces

What does this MR do and why?

What it does:

• integration part of sylva-projects/sylva-elements/container-images/libvirt-metal#11 (closed), to test libvirt-metal support for both bonding (for management cluster) and standalone interfaces (for workload cluster), following reintroduction of the latter in sylva-projects/sylva-elements/container-images/libvirt-metal!88 (merged)

• related to the previous point, it also dumps preprovisioning-netdata Secrets (not created by CAPI), to aid in future troubleshooting

• integration of sylva-projects/sylva-elements/container-images/libvirt-metal!104 (merged) (merged from !3159 (merged), if you think the git history will look bad, I can squash the merge commit).
  This change would have ci-featuretest-upgrade-from-1.1.1 labeled MR or Nightly - Upgrade from 1.1.1 to main CI jobs fail the upgrade steps, if now the HelmRelease.spec.targetNamespace would enforce redeployment of libvirt-metal pods in sylva-system, rather than default ns. But it's not happening because for capm3-virt infra the libvirt-metal version is fixed to 0.1.15 in ci-tooling/ci-deployment-values common/libvirt-metal-no-bond.yaml, by this CI config.

  Later edit: I was wrong, !2852 (f488d984) would have the CI specific additions forced in sylva-system, so it will need the other way around, to have the 1.1.1 initial deployment be done directly in sylva-system ns, so also to upgrade tag to 0.1.21. So it may be better if we merge this after the sylva-core tagging of 1.1.2 happens.

Related reference(s)

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, oci, ha, misc
🎬	Pipeline Scenarios	rolling-update, mgmt-rolling-update, k8s-upgrade, sylva-upgrade, sylva-upgrade-from-x.x.X, simple-update, preview, nightly

• 🎬preview ☁️capd 🚀kadm 🐧ubuntu 🛠️oci

• 🎬preview ☁️capo 🚀rke2 🐧suse

• 🎬preview ☁️capm3 🚀rke2 🐧ubuntu

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

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

• ☁️capo 🚀rke2 🛠️oci 🐧suse

• ☁️capo 🚀kadm 🛠️oci 🐧ubuntu

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

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

• ☁️capo 🚀rke2 🎬mgmt-rolling-update 🛠️ha,misc 🐧suse

• ☁️capo 🚀rke2 🎬sylva-upgrade 🛠️misc 🐧ubuntu

• ☁️capm3 🚀rke2 🐧suse

• ☁️capm3 🚀kadm 🛠️oci 🐧ubuntu

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

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

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

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

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

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.