catalog: use configmap for leader election lock

This changes the leader election lock to use a configmap rather than an
endpoint. In addition to endpoint locks eventually probably moving to
deprecation, this allows customers to more easily determine which catalog
controller has won leader election.

roles/openshift_service_catalog/files/kubeservicecatalog_roles_bindings.yml

@@ -182,12 +182,12 @@ objects:
 - apiVersion: authorization.openshift.io/v1
   kind: Role
   metadata:
-    name: endpoint-accessor
+    name: configmap-accessor
   rules:
   - apiGroups:
     - ""
     resources:
-    - endpoints
+    - configmaps
     verbs:
     - list
     - watch
@@ -198,9 +198,9 @@ objects:
 - apiVersion: authorization.openshift.io/v1
   kind: RoleBinding
   metadata:
-    name: endpointer-accessor-binding
+    name: configmap-accessor-binding
   roleRef:
-    name: endpoint-accessor
+    name: configmap-accessor
     namespace: kube-service-catalog
   subjects:
   - kind: ServiceAccount

roles/openshift_service_catalog/templates/controller_manager.j2

@@ -36,6 +36,8 @@ spec:
         - "5"
         - --leader-election-namespace
         - kube-service-catalog
+        - --leader-elect-resource-lock
+        - configmaps
         - --broker-relist-interval
         - "5m"
         - --feature-gates