feat: add environment values handling for automatic host patching

[hisco]

Summary

• Adds a new "Apply environment values" step to kustomize-edit that reads environment-values.env and generates kustomize patches for recognized keys
• EXTERNAL_HOST handler: replaces hosts in Ingress (rules + TLS) and HTTPRoute resources
  • Simple mode: EXTERNAL_HOST=preview.myorg.dev — replaces all hosts
  • Mapping mode: EXTERNAL_HOST=old->new,old2->new2 — replaces specific hosts
• Resource discovery via kustomize build with recursive file scan fallback
• Idempotency: prefix-based cleanup removes old generated patches before regenerating
• Backward compatible: no-ops gracefully when env file is missing, empty, or contains only unrecognized/malformed keys; preserves existing user patches and kustomization fields

New inputs

• environment_values_file (default: environment-values.env)
• patch_prefix (default: random skyhook-<8hex>-)

New outputs

• applied_environment_keys — comma-separated keys that were processed
• skipped_environment_keys — comma-separated unrecognized keys

Test plan

• 68 tests passing locally (bash test_environment_values.sh)
• Verify single-rule, multi-rule, TLS, HTTPRoute, and mixed resource scenarios
• Verify mapping mode replaces only matching hosts
• Verify idempotency (re-runs produce identical output, no duplicate patches)
• Verify backward compat: no env file, empty file, malformed lines, unrecognized keys, existing patches preserved
• Verify existing test_set_images.sh tests still pass (57/57)

[nadaverell]

why do we need this? isn't this just temp for the CI job? not sure why this would be worthwhile for someone to bother with changing?

[hisco]

u mean specially the 'patch_prefix'?

We intend this will be used for ephemeral use case only.
However, if someone will use this feature for a non ephemeral use case.
Or if preview env will be persisted to git (i.e because using argocd).

Then the result files will have random file names, this will be ugly and functionally broken.

[nadaverell]

Fix tests - lets see them passing in CI

[nadaverell]

Ok having given it more thought I have a few major concerns with this:

1. It pretends to be generalizable but nothing is actually written as generalizable. This is specifically for hostname and the interface and everything should be structured accordingly. Wrapping it in fake API that implies some generalized functionality just makes everything harder for some very unknown future thing that the code doesn't even come close to supporting.

2. The output/result is not sufficiently considered here. For pure GHA CI this isn't a big deal because it's all ephemeral. But if this is used in GitOps, this gets written to repo. Then, this whole random prefix stuff is actively harmful IMO. Why do we need this and not a dedicated patch format? The PR and the tests don't really show me what this would look like in real user's repos, especially the more complicated cases. There's no "this is what the result looks like" to review here...

3. We moved away from patches for ingress to components, isn't this just moving us back, just with automation of the patch generation? I'm losing track of what we're accomplishing here. Can you explain more clearly - input (what the repo looks like before this), output (what the repo looks like after this), what the core value for the user from this approach?