Migrate resource_link_events to ghost users

Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/416588

When a user is destroyed, we should either associate the DB records that reference the user to ghost user or allow the reference column to be nullable.

Because resource_link_events table's user_id is not nullable, we should migrate its rows to be associated to ghost user on user deletion.

This MR does:

1. Updates the AR model for resource_link_events so it is associated to users at the application level.
2. Updates EE::Users::MigrateRecordsToGhostUserService so that resource_link_events rows are migrated appropriately.

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.

changed milestone to %16.2

added Category:Error Tracking Category:MLOps Category:System Access Model Experiments bugtransient devopsmanage groupauthentication and authorization [DEPRECATED] sectiondev typebug workflowin review labels

assigned to @euko

@ifarkas

I moved the changes to the main repo. Could you set MWPS please? Thanks in advance!

requested review from @ifarkas

added backend label

Reviewer roulette

Changes that require review have been detected!

Please refer to the table below for assigning reviewers and maintainers suggested by Danger in the specified category:

Category	Reviewer	Maintainer
backend	David Dieulivol (@ddieulivol) (UTC+2, 7 hours behind @euko)	Drew Cimino (@drew) (UTC+0, 9 hours behind @euko)

To spread load more evenly across eligible reviewers, Danger has picked a candidate for each review slot, based on their timezone. Feel free to override these selections if you think someone else would be better-suited or use the GitLab Review Workload Dashboard to find other available reviewers.

To read more on how to use the reviewer roulette, please take a look at the Engineering workflow and code review guidelines. Please consider assigning a reviewer or maintainer who is a domain expert in the area of the merge request.

Once you've decided who will review this merge request, assign them as a reviewer! Danger does not automatically notify them for you.

If needed, you can retry the danger-review job that generated this comment.

Generated by Danger

Allure report

allure-report-publisher generated test report!

e2e-test-on-gdk: test report for 0283e4a7

expand test summary

+-------------------------------------------------------------+
|                       suites summary                        |
+--------+--------+--------+---------+-------+-------+--------+
|        | passed | failed | skipped | flaky | total | result |
+--------+--------+--------+---------+-------+-------+--------+
| Manage | 1      | 0      | 0       | 0     | 1     | ✅     |
+--------+--------+--------+---------+-------+-------+--------+
| Total  | 1      | 0      | 0       | 0     | 1     | ✅     |
+--------+--------+--------+---------+-------+-------+--------+

approved this merge request

@ifarkas, thanks for approving this merge request.

This is the first time the merge request is approved. To ensure full test coverage, a new pipeline will be started shortly.

For more info, please refer to the following links:

• rspec predictive jobs
• jest predictive jobs
• merging a merge request.

added pipeline:mr-approved label

enabled an automatic merge when the pipeline for bb8dc7f1 succeeds

merged

mentioned in commit 544cf38b

added workflowstaging-canary label and removed workflowin review label

added workflowcanary label and removed workflowstaging-canary label

added workflowstaging label and removed workflowcanary label

added workflowproduction label and removed workflowstaging label

added workflowpost-deploy-db-staging label and removed workflowproduction label