feat: add OCI support for Argo CD sources

[robinlieb]

Description

This PR adds the capability to mutate OCI references in Argo CD resources and replaces the given OCI reference to the Zarf registry URL.

This change adds the possibility to use Manifest and Helm Charts in the repoURL in the Application, like explained in the OCI Docs in Argo CD with the first two examples. To archive that it also changes the patching of the URL in repository secrets to use the registry instead of the git server if oci is used.

Related Issue

Relates to #3046

Checklist before merging

• Test, docs, adr added or updated as needed
• Contributor Guide Steps followed

[netlify]

✅ Deploy Preview for zarf-docs canceled.

Name	Link
🔨 Latest commit	9007e84
🔍 Latest deploy log	https://app.netlify.com/projects/zarf-docs/deploys/69162c432c9b0f0008f4b904

[brandtkeller]

Made a first pass - spent a healthy amount of time educating myself on argo further.

Left a nit that I think we can cleanup in a few places. Separately want to consider some additional scope for this change:

1. E2E testing - unit tests get us some good feedback loops on the internal dependency and behaviors but this is largely an external integration. I would love to think about how we test this is operational.
2. Documentation - right now this can be appending to the existing tutorial. There may be more opportunity for a more granular pass at argocd orchestration docs.

Two minor requests:

1. Can you comment on an issue if/when you pick it up for work (or at least with the PR) - In doing so we can assign you and help prevent any colliding submissions (as well as remember to track for reviews on the project board.
2. Add context to the PR description. It took me a fair bit of reading to tell that the associated issue was asking for a feature around oci registries when you actually solved for oci images. The former isn't actually as valid and you solved the problem correctly here IMO - but I had to hunt down the delta and process.

Thank you for the continued support and contributions - I very much appreciate it!

[brandtkeller]

Nit: for code patterns used across zarf (of those replaced thus far) we have been upgrading to use the happy path is left-aligned concept whereby - when possible we process conditions and return early and avoid else returns.

[robinlieb]

@brandtkeller thanks for the initial review. I added changes which addresses all of the mentioned points.
Added two applications in the Argo CD examples showcasing the the use of Helm Charts and manifests from OCI.
Added E2E test on base of this example.
Also refactored the patch logic for Argo CD resources since this contained some duplication.

For the other two points, will definitely keep that in mind for future work.

Update: For the sake of proper documentation, should I create a new issue specifying the OCI support for manifests?

[al-jeyapal]

The issue we might have with this is that ArgoCD will try to hit the registry over HTTPS. We were getting this in the Argo logs:

Failed to load target state:
 failed to generate manifest for source 1 of 2:
   rpc error: code = Unknown desc = failed to resolve revision "0.0.0":
     cannot get digest for revision 0.0.0:
       Head "https://zarf-docker-registry.zarf.svc.cluster.local:5000/v2/helm-charts/manifests/0.0.0":
         http: server gave HTTP response to HTTPS client

Helm allows you to use http via:

 helm pull --plain-http oci://...

However it doesn't look like Argo exposes an option for that. It exposes a --insecure-skip-server-verification but that only allows it to trust unverified certs.

We're currently trying to work around this by putting an internal caddy service to act as a HTTPS proxy in front of the zarf registry (on #4327). Still working through the details.

The easier option would be to have a HTTPS endpoint exposed on the zarf registry (just internally as a service not as an ingress/GatewayAPI route), even if it just uses a self-signed certificate. Not sure if that's a route we want to take though.