refactor: consolidate dual ingress resources into unified configuration.

[pantierra]

Closes #449 (fixes deployments with STAC only service).

This PR consolidates the ingress configuration by merging two ingress resources into a unified configuration. They have been there to address the problem that there are services that:

• Need path prefix stripping (raster, vector, multidim, mockOidcServer, docServer) - for routing with Traefik middleware
• Don’t need path prefix stripping (STAC, browser) - services that handle their own path routing

Previously, this was solved with two separate ingress resources (ingress.yaml and ingress-no-prefix.yaml), which was difficult to maintain and eventually caused issues such as #449.

Therefore this PR proposes:

• to removeingress-no-prefix.yaml and refactor ingress.yaml with shared path template
• to consolidate all service paths into a single eoapi.ingressPaths helper template
• to add conditional rendering logic ($hasEnabledService) to prevent creating ingress resources with empty path arrays

[spwoodcock]

This looks ideal 🙌 Thanks for addressing it so promptly!

For context, I was looking into was to host pgstac-fastapi via k8s and had previous experience with eoAPI. I reached for this chart and it made the process super simple - seems like the best way to spin up a quick STAC to me 😁

The only thing I would comment is that the ingress definition in values.yaml seemed a bit fragmented between the global ingress and individual service ingress.

It would be great to stick to one pattern or the other:

• A global ingress key to define all the domains per service.
• Probably better, would be removing the global ingress key if possible, making all ingress configuration per-service - a nice logical separation.

But its not a huge deal honestly, and changing this would of course introduce a breaking change, which is a bit of a pain

[pantierra]

Thanks, @spwoodcock for having a look!

Yes, you are right, it is worth to reflect on the global ingress configuration. It is definitively a tradeoff for operational simplicity, depending on the use case. For now I added a bit more pieces of documentation to make it clear. In the future we could consider rethinking this part, but i would prefer not to do this in this PR.