Description of problem:

Seen in https://issues.redhat.com/browse/ACM-6127 and https://issues.redhat.com/browse/ACM-4486 ; in the SD environment, we have seen that after creating a new hypershift cluster, the config-policy-controller pod for the cluster is redeployed a few minutes after its initial creation. This can interrupt initial policies that are being applied, and delay the cluster from being considered ready.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

1. Create a new hypershift cluster to be managed by ACM
2. Observe the new deployments for the policy components.

Actual results:

The policy pods are initially deployed without the "kube-rbac-proxy" container. After a ClusterClaim is created for the managed cluster identifying it as an OpenShift cluster, the policy-addon-controller adds that container to the deployment, causing the existing pods to be removed.

Expected results:

The initial deployment of the policy addon pods are stable, and initial policies can be applied quickly.

Additional info:

There are two suggestions from the discussion in 6127:

1. There may be a hosted mode annotation on the ManagedCluster resource, which the policy-addon-controller can read during the initial creation, and which we can assume means the cluster is an OpenShift cluster.
2. The ManagedCluster resource created by SD may already have the `vendor: OpenShift` label set, which could be read by the policy-addon-controller instead of waiting for the ClusterClaim.