KTF should not provide opinionated generic objects

The opinionated aspect of

https://github.com/Kong/kubernetes-testing-framework/blob/78b1222c5bb752093421eadce1bc5e6c2c38dc7c/pkg/utils/kubernetes/generators/ingress.go#L27-L60

is a problem. KTF does not know enough about its test users to have good opinions. In recent anecdotal history, the above was incorrect in assuming:

- that `Prefix` is an appropriate path type for most cases. In KIC's case, `ImplementationSpecific` is usually the best choice because it's the simplest implementation. `Prefix` results in its own opinionated regex route configuration, adding more complexity to route selection and preventing you from writing your own regular expressions. This notably broke almost all tests after the 3.x regex change, which was incredibly confusing.
- that test Ingresses only need one rule.
- that test Services only have one port, or that their first port is the correct port.
- that test Ingresses do not require TLS configuration.

This function is currently used throughout KIC's test suites. We cannot easily add features to it because we'll need to update signatures for compatibility across many locations, or change its behavior without worrying about unexpected breaking changes. Even if we do wish to make these changes, they require a separate KTF release, which adds friction.

While you can modify the Ingress after the fact, you may need to duplicate part of the utility's inherent functionality (setting the Service target in additional rules, for example). I think we

I think we can avoid these issues by pushing the burden of creating an initial opinionated template resource to the test suites. The KIC test suite knows enough about its domain to choose a usually sufficient template Ingress that can be copied and modified as needed. KTF, on the other hand, should provide unopinionated bulk action helper functions. NewIngressForService seeks to provide an Ingress for a Service, and it can satisfy the latter part of this without generating the Ingress itself. An alternative helper would take a an input Ingress, Service, and port name/number and update existing paths' backends to use it. This solves the problem of static Ingresses not being able to address randomly-generated Services on their own without controlling other unrelated aspects of the Ingress.

A more complex variant could allow you to selectively update rules: it would update all backends by default but optionally take a `map[int][]int` and update only those backends indicated by the rule index->path index pairs indicated by the map.

While this is more a general principle that probably applies to other KTF utilities, the immediate tasks here are:

- [ ] Add a new function that takes an Ingress, Service, and port, and returns a modified copy of the Ingress with path backends updated to that Service/Port. Optionally take a list of rule/path indices and return a copy with _only_ those updated.
- [ ] Replace several uses of `NewIngressForService()` in KIC with a static Ingress defined in KIC's test suite and a call to the new function. Ripping out all instances of the existing function would be tedious. We'd like to move away from `NewIngressForService()` but don't strictly need to do so immediately.

Start with pkg/utils/kubernetes/generators/ingress.go, especially NewIngressForService and the linked generator code. Search the KIC test suites for its uses and determine which static Ingress definitions need to replace them. Done means a helper returns a modified Ingress with selected or all path backends updated to the requested Service and port, while existing uses are migrated as appropriate.

Written by the indexing model from the issue text.