improve tooling around sylva-core Git repo (smaller GitRepository clones, check that commit was pushed)

**Co-authored with @jonathang **

This MR does two things to improve Git-based tooling :

• first, it allows to clone less data for the FluxCD GitRepositories for sylva-core

  • FluxCD has some ability to use "shallow clones" (or well, "near shallow clones, see below), ie to minimize the amount of data retrieved from Git
  • depending on the GitRepositories.spec.ref this is more or less efficient:
    • today we use ref.commit which does not allow "shallow cloning" at all (we clone ~25Mi each time)
    • we can improve this by using ref.branch + ref.commit, which allows to have a "single branch" clone (we would then typically retrieve ~19Mi of data)
    • as detailed in the threads of this MR, we tried to obtain "really shallow clones", where the data retrieved is minimized to the current commit, but we didn't manage to (we being @tmmorin, @jonathang) -- this would have allowed in theory to download only 6Mi
  • what this MR does is to add to the GitRepository.spec ref, the branch (and/or the tag) if a branch (and/or a tag) is found for the current commit
  • the downloaded data should typically be around ~19Mi (instead of ~25Mi)
  • this optimization will always applicable, since our commits are always on a given branch

• when implementing the evolution above, it made sense to ensure that the current commit was existing remotely, or else we would have the possibility of the remote Git dev branch be out-of-sync with the local local dev branch so this MR adds a check that the current commit has been pushed to the remote Git -- this check is useful to have on a daily basis anyways, independently from the evolution for smaller Git clones

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
🎬	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 🛠️ dev-sources,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,misc 🐧 suse

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

• ☁️ capm3 🚀 rke2 🐧 suse

• ☁️ capm3 🚀 kadm 🛠️ dev-sources 🐧 suse

• ☁️ 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 🛠️ misc,ha 🐧 suse

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

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.