Notebook Controller Leader Election

/kind bug

**What steps did you take and what happened:**
[A clear and concise description of what the bug is.]
When deploying notebook-controller via `v1.6.0-rc.0` the `manager` container of `notebook-controller` failed to start to due to missing permissions to `get,create,patch` `coordination.k8s.io` `leases` for the leader-election resource. I got past the issue by creating a patch in my manifests repo to add the leader-election permissions needed.

**What did you expect to happen:**
The leader-election role found [here](https://github.com/kubeflow/kubeflow/blob/master/components/notebook-controller/config/rbac/leader_election_role.yaml), should have the below config added to prevent notebook controller from failing to start if leader election gets enabled.

```
apiGroups:
- coordination.k8s.io
resources:
- leases
verbs:
- get
- list
- create
- update
- delete
- patch
- watch
```

**Anything else you would like to add:**
I think this issue came about updating the notebook-controller go version to `1.17` as this was not an issue before in kubeflow `v1.5.0`.

**Environment:**

- Kubeflow version: (version number can be found at the bottom left corner of the Kubeflow dashboard): `v.1.6.0-rc.0`
- Kubernetes platform: (e.g. `minikube`) eks
- Kubernetes version: (use `kubectl version`): 1.21

Start with components/notebook-controller/config/rbac/leader_election_role.yaml and compare its rules with the leader-election permissions described in the issue. Render or apply the manifests in a Kubernetes environment, then verify that the notebook-controller manager starts successfully with leader election enabled and has the required lease permissions.

Written by the indexing model from the issue text.