When working on [Selected groups are not persisted for allowed to merge / allowed to push and merge sections](https://gitlab.com/gitlab-org/gitlab/-/issues/467343) bugs, we realised that the bug originated from a wrong API call for groups. Trying to fix it by fetching groups with project aspect, we ran into another inconsistency: - [using `Api.projectGroups`](https://gitlab.com/gitlab-org/gitlab/-/blob/09be442a056294b72923b8fa2ea6c7a22cce95c7/app/assets/javascripts/vue_shared/components/list_selector/index.vue#L153) got us all the groups with project access, including the group that owns that project. However, it did fail the validation when creating the branch protection because: > @jwoodwardgl: I think this is correct. Only invited groups can be used, all the members in the project's group are already inherited members so we can give developers access by selecting the `Developers + Maintainers` role. > > [When granting a group Allowed to merge or Allowed to push and merge permissions on a protected branch, **_the group must be added to the project_**.](https://docs.gitlab.com/ee/user/project/protected_branches.html#for-one-project) _here [link to the discussion](https://gitlab.com/gitlab-org/gitlab/-/issues/467343#note_1980312421)_ - in Project Settings/Repository/Protected branches [we use a different endpoint to get groups with the project access](https://gitlab.com/gitlab-org/gitlab/-/blob/43f70166d6335d56cb7ae5234977ca803696e4ee/app/assets/javascripts/projects/settings/api/access_dropdown_api.js#L28). The response differs from the other one only by the owning group. The set of groups is **almost** identical, but we still need to accommodate a shared component to using different endpoints, even when that component is used multiple times on one page (see Branch rules details page that encompasses protected branches and MR approval rules).