Raise the permissions of the group-level APIs to owner
🚨 Please remove confidential of this issue when https://gitlab.com/gitlab-org/gitlab/-/issues/364441 gets released!
In https://gitlab.com/gitlab-org/gitlab/-/issues/364441 we identified a discrepancy between the UI & the API Group Owners / administrators permission for package and registries settings.
## Context
Currently, the docs show that maintainers should have the ability to change these settings: https://docs.gitlab.com/ee/user/permissions.html#group-members-permissions
We [recently updated the graphql/api permissions](https://gitlab.com/gitlab-org/gitlab/-/issues/350682) to be maintainer from developer to conform with the frontend. It looks like we got mixed up somewhere in https://gitlab.com/gitlab-org/gitlab/-/issues/350682 and https://gitlab.com/gitlab-org/gitlab/-/issues/322055 and the UI has required owner all along.
Access to the settings tab, & therefore Packages & Registry settings on the left side is [available](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/sidebars/groups/menus/settings_menu.rb#L9) only for group owners (they have `:admin_group` set on their [group policy](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/policies/group_policy.rb#L185)) and the same [check](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/controllers/groups/settings/packages_and_registries_controller.rb#L7) is made if the user tries to visit the URL directly. So maintainers don't have access to this UI.
## Proposed solution
Raise the permissions of the group-level APIs to `owner`.
The [note warning of the deprecation in GraphQL](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/96387) should be removed.
Relates to https://gitlab.com/gitlab-org/gitlab/-/issues/364441
## Breaking change tasks
### Affected Topology
This affects Self-Managed users of GitLab.
### Affected Tier
All tiers are affected.
* Free
* Premium
* Ultimate
### Checklists
**Labels**
- [ ] This issue is labeled ~deprecation, and with the relevant `~devops::`, `~group::`, and `~Category:` labels.
- [x] This issue is labeled ~"breaking change" if the removal of the deprecated item will be a [breaking change](https://about.gitlab.com/handbook/product/gitlab-the-product/#examples-of-breaking-changes).
**Timeline**
Please add links to the relevant merge requests.
- As soon as possible, but no later than the third milestone preceding the major release (for example, given the following release schedule: `14.8, 14.9, 14.10, 15.0` – `14.8` is the third milestone preceding the major release):
- [x] A [deprecation announcement entry](https://about.gitlab.com/handbook/marketing/blog/release-posts/#creating-a-deprecation-announcement) has been created so the deprecation will appear in release posts and on the [general deprecation page](https://docs.gitlab.com/ee/update/deprecations). - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/108055
- [ ] Documentation has been updated to mark the feature as [deprecated](https://docs.gitlab.com/ee/development/documentation/versions.html#deprecations-and-removals).
- [x] On or before the major milestone: A [removal entry](https://about.gitlab.com/handbook/marketing/blog/release-posts/#removals) has been created so the removal will appear on the [removals by milestones](https://docs.gitlab.com/ee/update/removals) page and be announced in the release post. - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/108055
- On the major milestone:
- [ ] The deprecated item has been removed.
- [ ] If the removal of the deprecated item is a [breaking change](https://about.gitlab.com/handbook/product/gitlab-the-product/#examples-of-breaking-changes), the merge request is labeled ~"breaking change".
**Mentions**
- [x] Your stage's stable counterparts have been `@mentioned` on this issue. For example, Customer Support, Customer Success (Technical Account Manager), Product Marketing Manager: @heather.
- To see who the stable counterparts are for a product team visit [product categories](https://about.gitlab.com/handbook/product/categories/)
- If there is no stable counterpart listed for Sales/CS please mention @timtams
- If there is no stable counterpart listed for Support please mention @gitlab-com/support/managers
- If there is no stable counterpart listed for Marketing please mention `@cfoster3`
- [x] Your GPM @jreporter has been `@mentioned` so that they are aware of planned deprecations. The goal is to have reviews happen at least two releases before the final removal of the feature or introduction of a breaking change.
### Deprecation Milestone
15.8
### Planned Removal Milestone
16.0
issue