Improve `AccessRequest` oidc vs token differentiation

[Diaphteiros]

What would you like to be added:
Our AccessRequest resource has evolved a bit recently and unfortunately has become more difficult to use. This is due to the fact that an AccessRequest can either create OIDC-based access or token-based access and depending on this, some of the fields are interpreted differently:

(all fields are inside spec)

Token:

• Each entry in permissions results in either a ClusterRole and ClusterRoleBinding or a Role and RoleBinding.
  • The scope is determined by whether the entry's namespace field is empty or not.
  • Subject for the bindings is always the service account that is created for the request.
• Each entry in roleRefs results in either a ClusterRoleBinding or a RoleBinding.
  • The scope is determined by the kind of the entry.
  • Subject for the bindings is always the service account that is created for the request.
• The oidcProvider field must not be set.

OIDC:

• Each entry in permissions results in either a ClusterRole or a Role.
  • The scope is determined by whether the entry's namespace field is empty or not.
  • Note that opposed to the token case, entries don't create bindings in the oidc case.
• The roleRefs field has no effect. It cannot be used, because the role references are missing a subject and there is no 'implicit service account' in the oidc case.
• The oidcProvider field must be set.
  • It has a roleBindings field that allows to specify a list of subjects and corresponding bindings, which result in ClusterRoleBindings and RoleBindings

The differentiation between token and OIDC case happens implicitly, depending on whether the oidcProvider field is set or not.

---

There is a lot of implicit logic in place and fields that change behavior depending on which other fields are set. This is likely to cause confusion among developers (AccessRequests are currently a purely internal resource that is not used by customers directly).

Here are some ideas on how this situation could be improved, let's discuss this topic soon:

Option 1: Explicit Differentiation

By adding a type or kind field that specifies either OIDC or Token, we would make the distinction explicit.

This is the least intrusive option, but it also has the least effect.

Option 2: Restructuring

Instead of having 'shared' fields that differ in meaning depending on the request type, we could have separate top-level fields for the OIDC and token cases. All configuration for the respective case is within the corresponding top-level field and only one top-level field may be set.

Can be combined with option 1 for a more explicit distinction.

Requires restructuring of the AccessRequest resource, but avoids fields that change meaning depending on other fields.

Option 3: Resource Split

We could also split the AccessRequest resource into two resources, TokenAccessRequest and OIDCAccessRequest.

This would solve all problems regarding the difficult configuration of the resource, because both cases are separated. However, this is also a lot of work: A completely new resource means that each ClusterProvider would need an additional controller for that resource. Migration will also be a problem.

[Diaphteiros]

We discussed this topic today and decided to go for option 2.