Database migration to correct vulnerabilities incorrectly transitioned by auto-resolve

Why are we doing this work

The new vulnerability management policy feature had a bug (#521907 (closed)) where vulnerabilities were incorrectly transitioned from dismissed to resolved. We need to create a background migration to correct these vulnerabilities back to their original state.

Customer reports

Active

1. https://gitlab.slack.com/archives/CPJTR33AQ/p1744759442737069
2. Vulnerability Management Policy Auto-resolve Pr... (#536314 - closed)
3. GitLab Security Policy Bot updated vulnerabilit... (#535613 - closed)
4. Dismissed entries in Vulnerability Report keep ... (#515785 - closed)

Mitigated (other issue, or migration is not needed)

1. https://gitlab.com/gitlab-com/request-for-help/-/issues/2693+

Relevant links

Non-functional requirements

• Documentation:
• Feature flag:
• Performance:
• Testing:

Implementation plan

1. Create a batched background migration that accepts two arguments:
   1. instance - boolean, migrate all vulnerabilities on the instance when set to true
   2. namespace_id - integer, namespace to migrate
2. Batch over in-scope vulnerabilities that are in the resolved or detected states.
3. Check the state transitions from newest to oldest.
   1. If we see a state transition where created_at is older than 2024-11-18 (when !172161 (merged) was first deployed), exit early.
   2. If we see a state transition where author does not have user_type = 10 (security policy bot), exit early.
   3. If we see a state transition where from_state is dismissed and to_state is resolved, push this vulnerability to the list of vulnerabilities to be reverted.
4. Bulk-update all the vulnerabilities to be reverted
   1. Change vulnerability state to dismissed
   2. Insert a new state transition to record this state change
   3. Insert a system note explaining why the state has been changed
5. Create a rake task which can be used to enqueue the migration with the arguments

Why not a normal migration?

See https://gitlab.com/gitlab-com/gl-infra/production/-/issues/19860#why-do-this-via-a-change-request

Verification steps