Better scalability testing

[matthchr]

We should strive to answer two questions:

1. At what point do we start to hit Azure throttling?
2. At what point do we start to have issues with the Kubernetes control plane (# of CRs)

Ideally we could define some upper bounds. Things to consider here are:

1. Spike in load on pod restart as it re-hydrates lists and sends requests to Azure.
2. Resource shape/size. K8s controlplane will have much less issue with tons of ResourceGroups (small) than tons of ManagedClusters (large).
3. Secrets integration: Some resources watch secrets, which means the operator is subscribed to secrets events, so possibly a ton of (unrelated) secrets activity could cause issues. Doubly so if the secrets activity is actually on secrets we're paying attention to.

[matthchr]

We're still interested in doing this, although our current experience suggests that we run into Azure scalability limits (request throttling) before we run into Kubernetes scaling limits on most things.

The obvious exception being CRD size driving APIServer memory usage

[matthchr]

We have now had a user report in #3934 that could possibly have been helped out by us having better testing here.