The System Upgrade Controller (SUC) tries to adopt the CRD, requiring
writing permissions, when it can read the CRD. Since we deploy the CRD
anyway, and SUC doesn't need to adopt the CRD. If it can't read CRDs it
just assumes they are all in order, therefore not trying to adopt them.

Therefore this patch removes the permission preventing errors.

This patch fixes the broken garbage collection that is caused by a bug
in the current calico release. This is done by manually upgrading to a
newer patch release of the tigera operator which incorporates a fix.

The garbage collection is currently broken due to a missing permissions
to 'projectcalico.org/v3 Resource=bgpfilters' which results in a stalled
cache sync for the kube-controller-manager garbage collector.

Error logs:
```
graph_builder.go:281] garbage controller monitor not yet synced: projectcalico.org/v3, Resource=bgpfilters
…
garbagecollector.go:250] timed out waiting for dependency graph builder sync during GC sync (attempt 43)
```
References
https://github.com/projectcalico/calico/issues/7715
https://github.com/kubernetes/kubernetes/blob/bb878608686a6276cefec3f51bee5d79b0c8c393/pkg/controller/garbagecollector/garbagecollector.go#L143-L175

This patch downgrades the tigera operator to an older version, since
calico currently shows some weird error. Until further debugged, this is
blocking other updates.

This reverts commit 331561d5.

This patch enables explicit pod security standards on all infrastructure
namespaces.

This patch prepares the switch to Kubernetes 1.24.x which switches to
PSS instead of PSP. Therefore it's a good start to prepare our most
important namespaces with the relevant labels to allow Pods to use
privileged runtime features.

References:
https://kubernetes.io/docs/concepts/security/pod-security-standards/
https://v1-23.docs.kubernetes.io/docs/concepts/security/pod-security-policy/
https://v1-23.docs.kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/

This patch Upgrades calico to version 3.23.0, which is a complicated
endeavour since it switches the helm release namespaces from default to
tigera-operator.

Besides the regular upgrade tasks, this reqires some explicit adjusting
of helm annotations and flux labels, in order to convince the cluster,
that's how it always has been.

The following tasks need to be done:

Before you start
---

Disable flux:

```
kubectl scale deployment -n flux-system source-controller --replicas 0
kubectl scale deployment -n flux-system helm-controller --replicas 0
kubectl scale deployment -n flux-system kustomize-controller --replicas 0
```

The upgrade
---

Push/merge this patch. (!!!)

Update helm release annotations:
```
kubectl patch installation default --type=merge -p '{"metadata": {"annotations": {"meta.helm.sh/release-namespace": "tigera-operator"}}}'
kubectl patch apiserver default --type=merge -p '{"metadata": {"annotations": {"meta.helm.sh/release-namespace": "tigera-operator"}}}'
kubectl patch podsecuritypolicy tigera-operator --type=merge -p '{"metadata": {"annotations": {"meta.helm.sh/release-namespace": "tigera-operator"}}}'
kubectl patch -n tigera-operator deployment tigera-operator --type=merge -p '{"metadata": {"annotations": {"meta.helm.sh/release-namespace": "tigera-operator"}}}'
kubectl patch -n tigera-operator serviceaccount tigera-operator --type=merge -p '{"metadata": {"annotations": {"meta.helm.sh/release-namespace": "tigera-operator"}}}'
kubectl patch clusterrole tigera-operator --type=merge -p '{"metadata": {"annotations": {"meta.helm.sh/release-namespace": "tigera-operator"}}}'
kubectl patch clusterrolebinding tigera-operator tigera-operator --type=merge -p '{"metadata": {"annotations": {"meta.helm.sh/release-namespace": "tigera-operator"}}}'
```

Patch flux labels:
```
kubectl patch installation default --type=merge -p '{"metadata": {"labels": {"helm.toolkit.fluxcd.io/namespace": "tigera-operator"}}}'
kubectl patch apiserver default --type=merge -p '{"metadata": {"labels": {"helm.toolkit.fluxcd.io/namespace": "tigera-operator"}}}'
kubectl patch podsecuritypolicy tigera-operator --type=merge -p '{"metadata": {"labels": {"helm.toolkit.fluxcd.io/namespace": "tigera-operator"}}}'
kubectl patch -n tigera-operator deployment tigera-operator --type=merge -p '{"metadata": {"labels": {"helm.toolkit.fluxcd.io/namespace": "tigera-operator"}}}'
kubectl patch -n tigera-operator serviceaccount tigera-operator --type=merge -p '{"metadata": {"labels": {"helm.toolkit.fluxcd.io/namespace": "tigera-operator"}}}'
kubectl patch clusterrole tigera-operator --type=merge -p '{"metadata": {"labels": {"helm.toolkit.fluxcd.io/namespace": "tigera-operator"}}}'
kubectl patch clusterrolebinding tigera-operator tigera-operator --type=merge -p '{"metadata": {"labels": {"helm.toolkit.fluxcd.io/namespace": "tigera-operator"}}}'
```

Remove flux labels from namespace:

```
kubectl label namespace tigera-operator helm.toolkit.fluxcd.io/namespace-
```

Get values:

```
helm get values -n default calico > values.yaml
```

Install calico:

```
helm repo add projectcalico https://projectcalico.docs.tigera.io/charts
helm install calico projectcalico/tigera-operator --version v3.23.0 --namespace tigera-operator --values values.yaml
```

Migrate flux helmrelease:

```
kubectl apply -n tigera-operator -f bootstrap/calico/release.yaml
kubectl patch helmrelease calico --type=json -p="[{'op': 'remove', 'path': '/metadata/finalizers'}]" -n default
kubectl delete helmrelease -n default calico
```

Delete old helm install:

```
kubectl delete secret -n default -l name=calico -l owner=helm
```

Starting flux again
---

```
kubectl scale deployment -n flux-system source-controller --replicas 1
kubectl scale deployment -n flux-system helm-controller --replicas 1
kubectl scale deployment -n flux-system kustomize-controller --replicas 1
```

References:
https://projectcalico.docs.tigera.io/archive/v3.23/release-notes/

Turns out the problem was based in the wiretrustee usage, that confused
calico, resulting in double-tunneling.

This reverts commit 8a519732.