Introduce a new approach to refresh authorizations on group member

What does this MR do and why?

This MR is implementing the idea mentioned in https://gitlab.com/gitlab-org/gitlab/-/issues/357479#note_924149652 (and its following discussion)

Changes are

• When a group member is being added/removed/updated:

  • Currently, we are enqueuing an authorizations refresh job for the user being added/removed/updated. This causes a problem with customers who run automations. Because automations run via the API, it happens extremely fast, with little to no delay in between - they keep on adding/removing/updating group members in a particular group. And since the jobs are enqueued per user, the deduplication key for Sidekiq here is the user_id. However, since they are adding a new user every time, the user_id differs across all jobs, so we aren't able to perform effective deduplication on these jobs.

  • With the change in the MR, instead of enqueuing the job for the user, we are going to enqueue jobs for the projects being affected due to the change in membership. And since this is going to schedule jobs for a bunch of projects, we are able to perform effective deduplication even if a new user is added/updated/removed again to the same group, because the key for deduplication is project_id and project IDs remain the same across these operations.

No changelog added as this is behind a feature flag.

Screenshots or screen recordings

These are strongly recommended to assist reviewers and reduce the time to merge your change.

How to set up and validate locally

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

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.