Add additional values files for better coverage with `ct install`

[bdalpe]

Based on #541, I propose we add a CI check that runs kubeconform against a number of common value files. Unit tests are great for ensuring logic, but can't ensure correctness when deployed to a Kubernetes cluster.

https://github.com/yannh/kubeconform

[mitchnielsen]

I'm up for this as another layer of validation, but worth mentioning a couple things.

From https://github.com/PrefectHQ/arrowstreet-integration-tests/blob/main/prefect_release_test/load_tests/flowrun_trigger/NOTES.md:

Kubeconform, similar to kubeval, only validates manifests using the official Kubernetes OpenAPI specifications. The Kubernetes controllers still perform additional server-side validations that are not part of the OpenAPI specifications. Those server-side validations are not covered by Kubeconform (examples: yannh/kubeconform#65, yannh/kubeconform#122, yannh/kubeconform#142). You can use a 3rd-party tool or the kubectl --dry-run=server command to fill the missing (validation) gap.

This means that the ct install that we do in CI is a bit more comprehensive because it installs the resources on a real cluster, at which point we should see any validation errors.

That said, this highlights the common problem of only one permutation of the configuration being deployed for validation. Given how many configuration options there are, it isn't really possible to deploy every possible permutation to a real cluster. Because of that, we rely pretty heavily on the unit tests - which weren't present for the pull secrets, leading to #541.

tl;dr: this sounds like a good addition for the added validation, but we should still be vigilant about unit tests. Even better, we should test the configuration we've added in a real cluster to make sure it looks how we expect - especially if that configuration isn't the default and therefore won't be tested in a cluster in CI.

[bdalpe]

Looks like ct install already supports this. Should just need some additional values files for more coverage. I'll do this instead of installing another tool.

Charts may have multiple custom values files matching the glob pattern '*-values.yaml' in a directory named 'ci' in the root of the chart's directory. The chart is installed and tested for each of these files. If no custom values file is present, the chart is installed and tested with defaults.
https://github.com/helm/chart-testing/blob/main/doc/ct_install.md