Use specialized worker to refresh authorizations on group share removal [RUN ALL RSPEC] [RUN AS-IF-FOSS]

What does this MR do?

This change implements #223851 (closed).

Premise

With !60693 (merged), we added a new finder Projects::Members::EffectiveAccessLevelFinder, that outputs the effective access level of all possible members to a particular project.

Now that we have this finder, we have made use of it in the new service class AuthorizedProjectUpdate::ProjectRecalculateService, which:

• takes a project as input.

• Figures out the current authorizations of different users to this project from the project_authorizations table.

• Figures out the fresh authorizations of different users to this project from the new Projects::Members::EffectiveAccessLevelFinder service.

• If there is any difference between these 2 results, it deletes and adds new records to the project_authorizations table as necessary.

All this will be executed from with AuthorizedProjectUpdate::ProjectRecalculateWorker asynchronously.

Advantages

This new approach helps us calculate new permissions in one go rather than enqueuing N different AuthorizedProjectsWorker jobs (where N = number of members in the group), which is what happens internally when we call link.group.refresh_members_authorized_projects.

From Kibana, this is over 210,000 jobs in the last 7 days (both the API and the controller calls the same service Projects::GroupLinks::DestroyService, where these jobs are enqueued from). With the new approach, this is just one single call to a service, no new jobs enqueued, which means 210,000 fewer enqueued jobs 🙂

Moreover, AuthorizedProjectUpdate::ProjectRecalculateService is very generalised approach to project authorizations refresh, so we can use the same service in most other places mentioned in the above screenshot as well so that we can get rid of all those jobs. 🤞🏼

Screenshots (strongly suggested)

Does this MR meet the acceptance criteria?

Conformity

• 📋 Does this MR need a changelog?
  • I have included a changelog entry.
  • I have not included a changelog entry because the changes are behind a feature flag.
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team

Related to #223851 (closed)