feat: set custom repository and use selectors on argocd applications

[merll]

📌 Summary

This PR adds two features to the otomi apply command:

• There are two environment variables, APPS_REPO_URL and APPS_REVISION, which allow configuring the repoURL and targetRevision of ArgoCD application manifests when using otomi apply-as-apps or otomi apply --tekton. This way, feature branches can be pushed to other locations than the public GitHub repo for experimental purposes.
• otomi apply --tekton supports selectors, e.g. by file or name, for selectively configuring the ArgoCD applications.

These two come in useful when testing a new version of an app, without pushing all incremental changes to GitHub. Also, using the selectors, it does not keep re-enabling apl-operator, reverting any potential changes sent from a local Otomi CLI. Application upgrades can be tested on top of different releases, e.g. main and the previous release, without creating a separate feature branch for each combination.

Example, which only updates a single app with a new chart (provided that the Core repo was mirrored to the cluster):

APPS_REPO_URL=https://gitea.mycluster.dev-akamai-apl.net/otomi/core.git APPS_REVISION=testing-chart-branch otomi apply -l pkg=testing-chart --tekton

🔍 Reviewer Notes

These changes are for development use. Without setting any environment variables or selectors, they should not affect the behavior of the apl-operator.

🧹 Checklist

• Code is readable, maintainable, and robust.
• Unit tests added/updated

[CasLubbers]

One comment. Code looks good to me

[merll]

I realized that using the selectors on apply with --tekton is now exactly the same behavior as apply-as-apps. I thought of reverting that part, but I did not find it intuitive that the --tekton flag ignores selectors and applies all apps, and without the flag it respects them. Either way, we should probably clean that up soon, and make a clear separation between apply and apply-as-apps.

[CasLubbers]

I realized that using the selectors on apply with --tekton is now exactly the same behavior as apply-as-apps. I thought of reverting that part, but I did not find it intuitive that the --tekton flag ignores selectors and applies all apps, and without the flag it respects them. Either way, we should probably clean that up soon, and make a clear separation between apply and apply-as-apps.

It's not exactly the same right? In the apply we also update the deployment state in the configmap and make sure that some k8s resources are there.
I was more thinking of splitting up the apply command into an Install command and an Apply command. There we could have better separation of concerns and also make the commands testable.