CODEOWNERS optional groups should display group members in MR approvals

Problem to solve

Currently, an optional approval group will display all possible approvers, however an optional CODEOWNERS approval group will not show any. This feels inconsistent and it would be useful to show members of the optional group

Proposal

Display all (public) members of approval groups.

Example screenshot

In this example, the Reviewers is an optional CODEOWNERS group containing the same group referenced under Default (@gitlab-org/secure/static-analysis-be), however only `Default is shown:

• CODEOWNERS File: https://gitlab.com/gitlab-org/security-products/analyzers/bandit/-/blob/4196e5d4fb14fc746fa24ebb948cffee32998013/.gitlab/CODEOWNERS
• MR: gitlab-org/security-products/analyzers/bandit!75 (closed)

User experience goal

• More consistency in MR approvals
• Easier discovery of expected approvers

Permissions and Security

Matching other approval groups, only public members should be shown. If @groupA is a private group, show none. If @groupB is a public group, show each member.

Documentation

See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/workflow.html#for-a-product-change

• Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/workflow.html
• If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html

Availability & Testing

This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier.

What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing?

Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance.

• Unit test changes
• Integration test changes
• End-to-end test change

See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning

What is the type of buyer?

What is the buyer persona for this feature? See https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/buyer-persona/ In which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#three-tiers