Make `DuckTypeGenerator` more flexible by allowing to configure name of root level `status` field

[php-workx]

Hey,

The DuckType generator is a great starting point for customizing which clusters get selected and adding additional information about clusters by adding more key/value pairs to the list elements.

The usage of this Generator seems (artificially) limited by the fact that there has to exist a status field in the K8s resource type.

https://github.com/argoproj/applicationset/blob/master/pkg/generators/duck_type.go#L160

This requires a custom resource definition before one can even start to use this generator. If we could make this more flexible (e.g., configuration of the name of this field to data), it would allow using default K8s resource types like Secrets and ConfigMaps.

Motivation:

We can't find a way to make more cluster-specific information (besides name and server) available to the ApplicationSet template. The metadata.labels.<key> and metadata.annotations.<key> work well for simple one-line strings (e.g., a AWS acmCertificateARN) but do not work for more complex multi-line information (eg, a public certificate).

Our idea was to use the DuckTypeGenerator to fetch a list of all clusters with all the additional information we need from a ConfigMap or Secret and then use the MergeGenerator to get this additional info merged with the list of clusters that the ClusterGenerator created.

BTW a much simpler way to achieve the above would be if we could directly support additional fields in the ArgoCD Cluster secret and make them available in the template as well:

https://github.com/argoproj/applicationset/blob/master/pkg/generators/cluster.go#L107

So instead of just fetching name, server, Annotations, and Labels, it would be great if we could support an additional field additionalInfo.<key> where all keys are available in the template.

Would be great to get some feedback on this idea. We would be happy to help with a PR ...

[MXfive]

Also have a similar use case here. I want to be able to more cleanly bridge the gap between Terraform and ArgoCD where Helm Releases (via ArgoCD Applications) need values (sometimes sensitive) from various places.

To be able to use this with ApplicationSet, we'd need to be able to pass in both a values file for each application, plus additional values which I'd compute from the previous values file and plucked from a Kubernetes Secret.