Draft: Migrate vulnerability approval rules

What does this MR do and why?

Migrate vulnerability approval rules into scan finding both on the DB level and project wise. It requires increasing permissions for the migration bot.

Related issue: #352307 (closed)

The advantage is to use a single user for all the actions involved. The drawback is the amount of privileges required in order to allow migration_bot to do it all.

A slightly different approach was tried which involved creating and merging a MR instead of pushing code directly. However the service for merging the MR was failing intermittently due to the short period between its creation and the merge action.

An alternative approach is to use resource token on the level of each project's namespace. It would create a bot user which could be used instead of the migration bot. The following example might better illustrate of how it fits in the worker:

# initial user to be used for the resource token creation
current_user = project.team.owners.first

# resource token is created on the scope of the project namespace
token_response = ::ResourceAccessTokens::CreateService.new(current_user, project.namespace,{ name: "migration helper", scopes:["write_repository"] }).execute

# from here onwards the code would be similar to the worker as described in this MR.
current_user = token_response.payload[:access_token].user

The advantage is the that this wouldn't require as many changes in regards to permissions. However it would require creating a resource token for each project namespace containing vulnerability-check rule. At the moment the amount of Vulnerability-Check rules is the following:

# select count(*) from approval_project_rules where report_type = 1;
 count
-------
  1604
(1 row)

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.