Refresh member authorized projects in background job

• Please check this box if this contribution uses AI-generated content (including content generated by GitLab Duo features) as outlined in the GitLab DCO & CLA. As a benefit of being a GitLab Community Contributor, you receive complimentary access to GitLab Duo.

What does this MR do and why?

This MR moves refreshing group member project authorizations into a background job. Given that the existing jobs are scheduled with a delay, the additional delay added by this background job shouldn't be a problem.

While this change doesn't solve the problem of executing a ton of SQL queries when enqueuing a lot of jobs, it does decouple this process from the request and therefore the 60s request timeout which is causing problems during project creation on groups with many members.

References

Please include cross links to any resources that are relevant to this MR. This will give reviewers and future readers helpful context to give an efficient review of the changes introduced.

Related to #523919 (closed)

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

No UI Changes.

Feature_flags_-_Google_Chrome_2025-03-08_20-07-28

How to set up and validate locally

1. Ensure you have Database Load Balancing enabled.
2. Create a group (just for isolation purpose, you could also use an existing group in GDK)
3. Create many members in the group. In my tests, I used 2000 members. FactoryBot.create_list(:group_member, 2000, source: Group.find(<id>)) in the rails console can help you.
4. Create a project in the group. (Ensure you have the devtools network tab open, so you can get the correlation id)
5. Copy the correlation id from the POST request that created the project, add it to the performance bar and select it.
6. Click on the count of the pg section from the performance bar, order chronologically, scroll down and notice many SELECT pg_wal_lsn_diff('0/296A3BF0', NULL) AS result and SELECT CASE WHEN pg_is_in_recovery() = true AND EXISTS (SELECT 1 FROM pg_stat_get_wal_senders()) THEN pg_last_wal_replay_lsn()::text WHEN pg_is_in_recovery() = false THEN pg_current_wal_insert_lsn()::text ELSE NULL END AS location; queries.
7. Enable the :project_authorizations_update_in_background feature flag (either globally or for the root group you are testing in)
8. Repeat step 4, 5 and 6. Notice that the queries mentioned in step 6 aren't present so many times.