Setting service.beta.openshift.io/inject-cabundle=true and config.openshift.io/inject-trusted-cabundle=true on the same ConfigMap causes infinite update loop

1. Proposed title of this feature request
Setting service.beta.openshift.io/inject-cabundle=true and config.openshift.io/inject-trusted-cabundle=true on the same ConfigMap causes infinite update loop

2. What is the nature and description of the request?
When creating a ConfigMap with the annotation service.beta.openshift.io/inject-cabundle=true set and the label config.openshift.io/inject-trusted-cabundle=true applied, we are ending up in a update race as both, the service-ca-operator as well as the cluster-network-operator are writing (trying to write) the certificate bundle to the ConfigMap.

Not only does this render the ConfigMap pretty much unusable as the content is never clearly defined or even in expected state but even worse, it generates a massive amount of requests on the OpenShift Container Platform 4 - API with unnecessary updates.

While it's clear that this should not be done, there is nothing that prevents users from doing this. Meaning if multiple projects are doing this, we can quickly generate a massive load on the OpenShift Container Platform 4 - API with update requests and therefore impacting other important/needed requests towards the OpenShift Container Platform - API.

Having a way to prevent such combinations from happening or where one definition takes precedence over the other would be welcome to protect the OpenShift Container Platform 4 - API from being overloaded.

• In worse case somebody could abuse this to potentially overload the API servers
  with the requests from these Operators

3. Why does the customer need this? (List the business requirements here)
There is no mechanism in place that would enforce precedence from one definition over the other or prevent such a combination from happening at all. Therefore there is always a risk that such a combination can be created or the situation is even abused and can overload the API server

Potentially just an alert that such a condition does exist would already be helpful to warn the Cluster Operator about this problem.

4. List any affected packages or components.

• service-ca
• network-operator
• API