Prevent OWNERS from inviting external members

Problem

When a MAINTAINER in a subgroup creates a new subsubgroup, they become OWNER of that subsubgroup. DEVELOPERS in subgroups are not allowed to create further subsubgroups, however, they are allowed to create projects. With Creator of new project does not get owner privi... (#17095) we are introducing the functionality to automatically making the DEVELOPERS creating projects OWNERS of these projects so that they can manage them.

The elevation to the level of OWNER causes some risks that we need to resolve:

• OWNERS are able to keep adding new members, which poses a security risk, but can also eat into licence seats.

• Example from a customer:

  People in this discussion have argued that developers' elevated permissions only apply to the subgroups/projects they create themselves. Essentially their argument is that any risk is limited to projects initiated by the developer themselves. This amounts to saying that operational controls should be able to be turned off by anyone if they want to operate without them, for their own work – that's clearly not a good idea and it's not how people expect permissions to behave.

  Controls are usually applied for a reason. The people applying the controls will expect that they apply to the whole group, including subgroups and projects, unless the person applying controls explicitly change the controls at another level.

  This isn't just academic, this has caused real problems for us. One of our maintainers created a subgroup and GitLab surprisingly gave them owner permissions in the new group. This gave them the ability to add users to the group and they added a user from outside our organisation. They hadn't gone through security or financial controls and we only found out about the new user when we did an audit of license seats.