Allow ConfigMaps and Secrets in post-build substitution to be absent

[seh]

Per earlier discussion in #558 (comment), it would be convenient if users of kustomize-controller's post-build susbstitution feature could opt in to allowing the referenced ConfigMap or Secret to be absent. At present, if the controller can't read the referenced ConfigMap or Secret, the reconciliation attempt fails. In some cases, especially where users use the variable expansion functions to supply a default value for an empty or missing placeholder value pulled from one of these referenced ConfigMaps or Secrets, there's no reason to create the referenced Kubernetes object until it's time to supply such a value. When users later wish to remove the overridden value, they could then simply delete the referenced ConfigMap or Secret, as opposed to editing its "data" field but needing to leave the object in place.

Consider adding a field to the api/v1beta2/SubstituteReference struct. That field could be of type bool and named something like "Optional" or "TolerateAbsence." There's some precedent in the Kubernetes API's types such as core/v1.ConfigMapVolumeSource and core/v1.ConfigMapProjection, along with their sibling types for Secrets. The default value of this field would be false, to retain the existing behavior.

Over in file controllers/kustomization_varsub.go in the substituteVariables function, if our call to the (*client.Client).Get method returns an error and this proposed SubstituteReference.Optional field is true, we'd check whether the error satisfies k8s.io/apimachinery/pkg/api/errors.IsNotFound. If it does, we'd skip the variable replacement and not report an error, as if the referenced ConfigMap or Secret existed but had an empty "Data" field.

This change would require documenting the new field in SubstituteReference, augmenting the substituteVariables function, and adding a few test cases in file controllers/kustomize_varsub_test.go to exercise the case of referencing a ConfigMap or Secret that does not exist, but with the proposed new field set to true.

Whether to make this new field of type *bool like the Kubernetes API does remains an open question.

[stefanprodan]

I'm in favour of this feature as we offer a similar thing in helm-controller when refereeing to values from ConfigMaps and Secrets https://github.com/fluxcd/helm-controller/blob/main/api/v2beta1/reference_types.go#L71-L75.