feat: Allow subjects to act as Owner to bypass the webhook

[KristianTrifork]

As a group of us have been discussing here: #1311

This feature adds a new flag in additionalRoleBindings which allows the subject to actAsOwner.
When a namespace is created, Capsule checks if the requester is owner of the Tenant, or if the Tenant has the actAsOwner flag set to true.
If so, the requester is allowed to create the namespace.

Here is a the Tenant used for testing:

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: oil
spec:
  owners:
  - name: alice
    kind: User
  - name: system:serviceaccount:tenant-system:tenant-gitops
    kind: ServiceAccount
  additionalRoleBindings:
    - clusterRoleName: admin
      actAsOwner: true # This is how the code is made in this PR
      subjects:
        - name: tenant-gitops
          kind: ServiceAccount

While this PR was being developed, we had a talk about what actAsOwner means. And where it should be.
In the discussion we aired a few places, and talked about the differences between them.

We believe the name and placement, should reflect what a delveoper would expect it to do.
And so we came up with a new idea, which would fit more in with the default of how the owners field works.
I'll paste a yaml example of how it could look like:

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: oil
spec:
  owners:
  - name: alice
    kind: User
  - name: system:serviceaccount:tenant-system:tenant-gitops
    kind: ServiceAccount
  additionalRoleBindings:
    - clusterRoleName: admin
      subjects:
        - name: tenant-gitops
          kind: ServiceAccount
  nameSpaceProvisioner: # This is the new field
    subjects:
        - name: tenant-gitops
          kind: ServiceAccount
          clusterRoleName: admin # If this is not set, it could default to a role simmilar to `capsule-namespace-provisioner`

The pros of the solution as it is this PR, the flag would be set, in the same place as the rolebindings are set.
The also means if the role giving does not have the RBAC to create a namespace, it would not be able to create a namespace.

In the second solution, the nameSpaceProvisioner would be a new field, which would be a list of subjects, which would be allowed to create namespaces.
This would match how owners works, and would be more intuitive for a developer to understand.

I would like to hear your thoughts on this, and if you have any other ideas on how to implement this feature.
The PR is set to WIP, as I still don't think we have settled on the best solution. And I think it's better to talk from code.

[netlify]

✅ Deploy Preview for capsule-documentation ready!

Name	Link
🔨 Latest commit	a587ce6
🔍 Latest deploy log	https://app.netlify.com/sites/capsule-documentation/deploys/679883af37a57600081d2663
😎 Deploy Preview	https://deploy-preview-1332--capsule-documentation.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[KristianTrifork]

@prometherion @maxgio92 @oliverbaehler

I've made a PR. My first time around Go and kubernetes operators. So I might need some pointers.

But I think it's easier if we have some code to talk from. And we had a busy week, so we didn't want it to run out in the sand. But I'd like to hear your thoughts.

[oliverbaehler]

I have time on the weekend to draft my proposal, thanks for your initial code

[KristianTrifork]

Is more required on my end before I could get feedback on this? :) I will make sure workflows work, but I am unsure if the current implementation is working as we discussed.

[KristianTrifork]

@oliverbaehler Hey.

Do you need anything more from me?