POC: Add member management as a deniable policy

Overview

In &4168 (closed), we're introducing a new policies framework to conditionally deny access to certain behaviors on a per-project basis. In regulated environments, the addition or removal of users to a project or group must follow an approval process and be documented. Other organizations want to spread the load and allow more users to manage group and project membership.

Proposal

Work on a POC to add project member management as an action that can be defined in a project Policy. During the POC, engineering will evaluate approaches to extend our current permission model to allow denying for specific actions. This model will ideally pave the way for fully custom roles in the future without introducing too much technical debt. We don't have to worry about UX for now but please consider the designs in #280534 (closed) and leave feedback there if anything discovered is incompatible.

Relevant background information:

• Research proposal
• Prototype allowing limited set of custom roles
• Project-level policy framework for deny epic

Availability & Testing

What risks does this change pose to our availability?

This is low risk to GitLab.com availability. However, one risk I see is the member management feature being (unintentionally) disabled for users that currently have them such as the project owners and admins resulting lockout of this feature.

What additional test coverage or changes to tests will be needed?*

• If the deniable policy is assigned to a user, they should not be able to add/remove user to the project from the UI as well as the API
• On GitLab.com, the deniable policy should not be applicable to owner users.
• If the user that has the deniable policy applied in a project is also part of another project in the same parent group, the deniable policy should not affect the user's ability to perform that action in the other project.