e2e test provisioning code for updating kustomize files

[surajssd]

We have this code for updating kustomize file in place for e2e tests. Which IMHO is highly confusing and goes in circles a lot.

Current state

• We provide properties file to the test provisioner. This is the current UX to update kustomize file.

https://github.com/confidential-containers/cloud-api-adaptor/blob/452f450f704223e19d410b509c744c8c711522b9/test/provisioner/provision_azure.properties#L1-L14

• The logic in properties file takes this and updates the kustomize file in place.
• As a new dev I have to learn which config from "properties file" translates into which other config in kustomize file.

https://github.com/confidential-containers/cloud-api-adaptor/blob/main/install/overlays/azure/kustomization.yaml

• As an experienced dev, person adding features to update kustomize file, I have to define new UX via properties file, write code, and educate everyone about this new UX etc.

• To add to that confusion some of the values in the properties file don't translate into any kustomize file config. But they suggest how the test should behave. So there is no consistency there too. I think this mixture of UX is highly confusing and detrimental to the dev productivity of the project.

Proposal

Let the e2e test author define the kustomize file directly, however they want. This is the same UX as a regular user of the CAA. We don't diverge from what users do and have more flexibility in writing tests.

---

Similar issue: https://github.com/confidential-containers/cloud-api-adaptor/issues/1286

[surajssd]

Another example that proves my point is in this PR: https://github.com/confidential-containers/cloud-api-adaptor/pull/1294. If we didn't have this whole code to update kustomization.yaml file I wouldn't have to create that PR.