Upgrade of Operator SDK to 1.3.0 / Kubebuilder to v3

[cimnine]

Summary

Applied the following advice:

• https://sdk.operatorframework.io/docs/upgrading-sdk-version/v1.3.0/
• https://master.book.kubebuilder.io/migration/project/v2_v3.html

Fixes #235

Checklist

• Keep pull requests small so they can be easily reviewed.
• Categorize the PR by setting a good title and adding one of the labels:
  bug, enhancement, documentation, change, breaking,
  as they show up in the changelog
• Update the documentation.
• Update tests.
• Link this PR to related issues.

[ccremer]

According to Kubebuilder migration guide, we can also remove this bit from leader_election_role.yaml:

  resources:
  - configmaps/status
  verbs:
  - get
  - update
  - patch

[ccremer]

So, related to #281 , I tried whether upgrading to controller-runtime to 0.7 will resolve the issue linked. It did not, but I've discovered other findings related to the upgrade.

I made a separate commit for it, but maybe it's probably best to upgrade this in a separate PR, because of the findings that we first should discuss.

[ccremer]

Opened discussion here: #288

[cimnine]

According to Kubebuilder migration guide, we can also remove this bit from leader_election_role.yaml:

This will become irrelevant when #289 is merged and when I've rebased, right? Please ignore.

[cimnine]

Rebased onto master

[ccremer]

I think you can remove my commit about upgrading the controller runtime. This should go into its own PR, e.g. #293 . this was for a test, but I can cherry-pick the commit locally to the other branch. Upgrading to 0.7 or 0.8 is also a K8s upgrade, so it's a big enough change to justify its own PR