Since upgrading to 1.5 we have an issue with our following setup:

cluster argocd creates a set of namespaces (foo-dev, foo-prod & foo-gitops), labels foo-dev and foo-prod to be managed by foo-gitops. Also the cluster-argocd deploys an ArgoCD instance into foo-gitops.

What happens is that there will be 2 missing RoleBindings in foo-gitops for the dex & redis server.

When labeling foo-gitops to be managed by foo-gitops it will create the rolebindings, but even then there seem to be some raceconditions.

It seems that the race condition happens when app.k.i label is set on the resources:

In a nutshell this is how to reproduce it:

```

$ oc delete project mh-dev mh-gitops
$ oc new-project mh-dev
$ oc new-project mh-gitops
$ oc label ns mh-dev app.kubernetes.io/instance=global-argocd-projects-app
$ oc label ns mh-gitops app.kubernetes.io/instance=global-argocd-projects-app
$ oc label ns mh-dev argocd.argoproj.io/managed-by=mh-gitops
$ oc apply -f /tmp/foo.yaml 
$ oc get roles -n mh-gitops-gitops
$ cat /tmp/foo.yaml
apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  finalizers:
  - argoproj.io/finalizer
  labels:
    app.kubernetes.io/instance: global-argocd-projects-app
  name: mh-gitops
  namespace: mh-gitops
spec:
  controller:
[...]

```

This has already been discussed with jfischer@redhat.com and reproduced (somehow).

This is a regression in 1.5 since it does not happen in <1.5.0 and it affects how folks are able to provision project and argocd as a service through argocd.