adapt MemberOverrides feature for v2

[Diaphteiros]

The Problem

To prevent customers from locking themselves out of their project/workspaces, the PWO webhooks prevent updating these resources if the user issuing the request is not part of the member list within the resource. The 'member overrides' feature is meant to enable landscape operators to modify projects/workspaces without having to put their own identity in the resource's member list.

In v1, this was done by a specific MemberOverrides resource on the onboarding cluster, which lists rbac subjects for which the aforementioned webhooks should not apply:

apiVersion: core.openmcp.cloud/v1alpha1
kind: MemberOverrides
metadata:
  name: landscape-operators
spec:
  memberOverrides:
  - kind: Group
    name: system:masters
    roles:
    - admin

The above example would treat everyone who has admin privileges on the onboarding cluster (by belonging to the k8s-default system:masters group) also as admin of all projects/workspaces, independent of whether the user is in the member list or not.

While there can be multiple MemberOverrides resources, only one can be active at a given time. In v1, the active one's name had to be passed into the PWO binary as a command-line argument.

When extending the PWO for v2, I simply moved the command-line argument into the PWO config, which is a k8s resource on the platform cluster in v2. The problem now is that v2 does create the onboarding cluster 'on the fly', it does not need to exist when the initial landscape setup is started. For any setup scripting, it would therefore be unnecessarily complex to put configuration on the onboarding cluster, which makes the current approach hard to use for v2.

The Solution

Since the v2 PWO has a ProjectWorkspaceConfig resource that serves as general configuration anyway, instead of just referencing a MemberOverrides resource in it, we could get rid of the MemberOverrides resource and move its configuration into the ProjectWorkspaceConfig directly.

Should be easy in general, what slightly complicates it is that the ProjectWorkspaceConfig resource is watched by the config controller (for the dynamic config reloading feature), so the webhook controllers need to fetch the member overrides information from this controller dynamically, instead only reading it on startup.

Definition of Done

• Content of current MemberOverrides spec is part of ProjectWorkspaceConfig spec.
• PWO v2 should not read any MemberOverrides resources anymore.
  • If possible, it should also not deploy the CRD for it anymore, but we might postpone this change until we get rid of the v1 implementation completely to avoid having to split between v1 and v2 resources during CRD deployment.
• Project and Workspace webhook controllers fetch member overrides information from the config controller whenever needed (the SharedInformation interface needs to be expanded for this, but this means that v1 will automatically keep working due to the v1 interface implementation).
• Documentation