cmd/k8s-operator,k8s-operator,go.{mod,sum}: publish proxy status condition for annotated services

[tomhjp]

Adds a new TailscaleProxyReady condition type to any corev1.Service that has been set up as a Tailscale proxy. This makes it easier to monitor the status of the proxy including any errors, and also enables users to run e.g. kubectl wait --for=condition=TailscaleProxyReady service nginx to wait until the proxy is ready to serve traffic.

The workflow to exercise that (assuming the operator is already deployed), would be something like:

kubectl run nginx --image=nginx
kubectl apply -f-<<EOF
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  annotations:
    tailscale.com/expose: "true"
spec:
  selector:
    run: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
EOF
kubectl wait --for=condition=TailscaleProxyReady service nginx

Fixes #12216

[tomhjp]

With the change to use metav1.Condition, the serialisation of the CRDs hasn't changed at all, they've just got some updated validation rules and descriptions. I manually checked all usages of setting conditions in the operator and didn't find any that would violate the new validation rules, so I think this should be safe.

I also tested:

1. Applying the old operator + CRDs
2. Creating a Service-based proxy and Connector subnet router
3. Rollout an operator from this PR
4. Observe successful condition changes
5. Rollout CRDs from this PR
6. Observe successful condition changes

[irbekrm]

Nice

[irbekrm]

Thanks @tomhjp , this looks great, I've played around with the new conditions for a bit and all seems to work as expected 🥳
I've left a couple nits, mostly optional.

We'll have to decide what to do with the redundant comment lines before merging. Generally, I am not as concerned about these as I was if this was in spec- I don't think anyone will really run kubectl explain connector.status.conditions (or, I never do) they will likely just run kubectl describe on the created resources at which point the condition messages should be self explanatory.
We could:

• see if we can get rid of the generated comments via codegen (we already do some hackery)
• revert using upstream conditions for our own types
• keep things as is in this PR (for now)

Maybe let's take a look if we can get rid of the comments and if not, then decide which of the other two?

[irbekrm]

Nice!

[irbekrm]

Looks great, thanks for working on this!

Glad about 121178c cleans up our test code a fair bit

[irbekrm]

We should also create another issue to do the same with Ingress resources

[tomhjp]

Thanks!