Description of problem

Since 4.20, some TechPreviewNoUpgrade Cluster-API ConfigMap release manifests have set binaryData, expecting the cluster-version operator to reconcile that property. And it is created for fresh installs, the first time the CVO creates the ConfigMap it just shovels the manifest content in. But on updates, the current CVO logic only checks for divergence in data, so it fails to notice or reconcile divergence in binaryData. We should fix that.

Version-Release number of selected component

4.19 is currently free of manifests trying to set binaryData:

$ oc adm release extract --to manifests quay.io/openshift-release-dev/ocp-release:4.19.20-x86_64
$ grep -r binaryData manifests
...no hits...

But starting in 4.20, there are some ConfigMap manifests trying to set that property:

$ rm -rf manifests
$ oc adm release extract --to manifests quay.io/openshift-release-dev/ocp-release:4.20.10-x86_64
$ grep -r binaryData manifests
manifests/0000_30_cluster-api_04_cm.infrastructure-aws.yaml:binaryData:

How reproducible

Every time.

Steps to Reproduce

1. Install a TechPreviewNoUpgrade cluster.
2. Edit some of the binaryData in the cluster's aws ConfigMap in the openshift-cluster-api namespace, like the components-zstd value.

Actual results

The CVO doesn't notice the edit, and fails to stomp it back to the manifest's preferences.

Expected results

The CVO notices the divergence, and stomps it back to the manifest's preferences.