feat: support kubernetes gateway api

[merll]

📌 Summary

This PR migrates from Ingress-Nginx to the Kubernetes Gateway API using Istio as an ingress gateway.

🔍 Reviewer Notes

There are two related PRs, that need to be considered during tests:

• feat: update manifests for gateway api apl-api#943: Required for Shell / TTY feature
• feat: separate services for selection by httproute apl-charts#42: Required for canary deployments

The migration process is implemented but requires changes in the following PR to work correctly. This should be merged first:

• fix: run pre- and post-upgrade consistently #3043

For avoiding a race condition between the ConfigMap update and the operator already reconciling, deactivate it temporarily:

1. disable auto-sync of apl-operator and scale down to 0, so that it does not sync while you make the following changes:

kubectl patch applications.argoproj.io -n argocd apl-operator-apl-operator --patch '[{"op": "remove", "path": "/spec/syncPolicy/automated"}]' --type=json
kubectl scale --replicas=0 -n apl-operator deployment apl-operator

2. update ConfigMap otomi/otomi-status field deployingVersion to 4.16.0:

kubectl patch configmap otomi-status -n otomi --type merge -p '{"data":{"deployingVersion": "4.16.0"}}'

3. then the version can be set to this feature branch (APL-1595-2)
4. scale apl-operator back up

kubectl scale --replicas=1 -n apl-operator deployment apl-operator

The following related PR has already been merged to reduce the diff of this one. It includes the CRD and a base chart for generic setup of Gateways:

• feat: add Gateway API CRDs and essential chart #3030

🧹 Checklist

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

[merll]

What would be procedure for allowing arbitrary NS to use platform SSO?

I can answer that question more clearly once I have solved the issue with token verification. It will likely involve adding an AuthorizationPolicy or modifying a common one, if we integrate it into the team-ns chart.

[ferruhcihan]

It appears that TTY might not need a ServiceEntry, whereas the Tekton Dashboard could require one. It would be great to confirm this, so we can make sure the configuration is correct for both.

[merll]

It appears that TTY might not need a ServiceEntry, whereas the Tekton Dashboard could require one. It would be great to confirm this, so we can make sure the configuration is correct for both.

Thanks for pointing out the missing entries. The ServiceEntry is only necessary for platform-internal traffic to find its way when using external host names. Missing some of them would likely go unnoticed in most cases, but for consistency I think it is better to have them in all cases. Therefore I added them.