Allow developers invited through group to read group runners

What does this MR do and why?

This MR adjusts the Ci::RunnerPolicy to allow developers to read runners (:read_runner) and runner managers (:read_runner_manager) associated with groups on which they are developers, either directly or indirectly.

Changelog: fixed

Fixes #364094 (closed)

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

The goal will be to create a runner on a group (top-level/group-with-runners) on which a user is not directly a maintainer. This is currently not allowed on master. Instructions created with inspiration from #364094 (comment 1183794964).

1. Ensure a minimum of two users exist. For this example I refer to them as root and user.

2. As root, create the following groups/subgroups (none of these are projects):

   • top-level
   • top-level/group-with-runners
   • user-management
   • user-management/admins

3. As root, invite user to user-management/admins with the Max Role of Owner.

4. As root, Invite subgroup user-management/admins to top-level with the Max Role of Owner.

5. As root, Configure a Runner on top-level/group-with-runners

6. As root, impersonate user.

7. While impersonating user, navigate to top-level/group-with-runners.

8. While impersonating user, confirm that you have Owner-level control to manage the Group (such as being able to see and change Settings).

9. While impersonating user, navigate to Build → Runners. Confirm that the Runner cannot be managed, but the number of Runners registered is displayed:

   

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.