Prevent projects from being shared outside a GMA group

Problem

When enforcing SSO and group-managed accounts, the desired experience is to require SSO for access to any projects and subgroups within a top-level group.

However, it's currently possible to share a project within a group enforcing SSO with a group outside of the top-level group's namespace - or by adding members outside the group directly to a project. While this has to be initiated by the group's Owner, this edge case has the potential to effectively subvert SSO enforcement.

Proposal

• When SSO enforcement is enabled for a group, present an error if:
  • A user attempts to share a project in the group outside the top-level group.
  • A user attempts to add members to the project who are not members of the group enforcing GMA.
• This should apply to projects in the GMA group, as well as projects forked from those projects.
• Sharing projects with subgroups within the top level group should be possible.

"GMA" here refers to Group Managed Accounts.

Availability & Testing

What risks does this change pose to our availability?

• Any existing access of groups outside the top level GMA group shared with a project in a GMA group gets revoked. (Would this be intentional/expected behaviour?)
• For forked projects, any existing access of groups outside the top level GMA group shared with the forked project in a GMA group gets revoked.
• The restriction is applied to SSO enabled groups that do not have GMA enabled.
• Share with group lock functionality breaks and allows sharing with groups with the same top-level group.

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

Tests and at unit and feature level should provide enough coverage. New End-to-end tests should not be required however, we should run the package-and-qa job before merging to ensure current tests are fine.