(temp) Enable hub authz and authn by default

[RedbackThomson]

Description of your changes

Prior to this change in spaces, authentication to a control plane supported using the the Kubernetes RBAC of the hub cluster. This meant as long as you used a cluster-admin to authenticate to the hub cluster, you could re-use those same credentials to authenticate to any of the control planes.

After that change, we expect that all authentication would go through Upbound IAM/RBAC by default. As such, ability to use Kubernetes RBAC was changed from opt-out to opt-in (breaking backward compatibility). However, Upbound IAM is only supported after connecting a space to cloud and the workflow for authenticating connected spaces is not yet ready. Therefore users cannot connect to any control planes from a spaces cluster running with the default values from version 1.3.1+.

This change opts-in to the Kubernetes RBAC values, rolling back to the previous default authn/authz model. These defaults should be reverted once support for connecting to control planes in connected spaces works end-to-end.

I have:

• Read and followed Upbound's contribution process.
• Run make reviewable to ensure this PR is ready for review.
• Added backport release-x.y labels to auto-backport this PR, as appropriate.

How has this code been tested

Running up space init --token-file=${userHome}/Keys/orchestration-build-b2e221ce1547.json v1.4.0-rc.0.40.gd33e4eb4 --set=account=upbound produces the following helm values:

$ helm get values spaces -n upbound-system
USER-SUPPLIED VALUES:
account: upbound
authentication:
  hubIdentities: true
authorization:
  hubRBAC: true
clusterType: kind

And up ctx can now connect to the control plane just like before:

$ up ctx
Kubeconfig context "kind-spaces-1.4" switched to: Upbound /kind-spaces-1.4/default/ctp1
$ k get pods
No resources found in default namespace.

[cbuto]

I think we'll also need to remove these defaults and fix the upgrade path to remove these when we make the switch (or documentation)

[RedbackThomson]

That is assuming we want to revert these defaults when people upgrade? I worry someone would end up relying on the RBAC and we'd break that accidentally when they upgrade.

Since this is technically a backward compatibility breaking change to the API, we can't revert it later unless the user explicitly allows us to do so.