Migration with access_token for approval project rules

What does this MR do and why?

This approach was preferred over the alternative as it requires less change in permission for migration bot. On the other hand it requires access token for each group containing at least one project with Vulnerability-Check.

Related issue: #352307 (closed) and #356996 (closed)

Currently there are 1706 vulnerability approval rules in prod:

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

from those 21 have orchestration project:

gitlabhq_dblab=# select count(*) from approval_project_rules inner join security_orchestration_policy_configurations on security_orchestration_policy_configurations.project_id = approval_project_rules.project_id wherqe report_type = 1;
 count
-------
    21
(1 row)

leaving 1685 without a security orchestration project.

Database (running migration)

$ bundle exec rails db:rollback
WARNING: This version of GitLab depends on gitlab-shell 13.25.2, but you're running 13.25.0. Please update gitlab-shell.
== 20220314154235 MigrateVulnerabilityApprovalRules: reverting ================
== 20220314154235 MigrateVulnerabilityApprovalRules: reverted (0.0000s) =======

$ bundle exec rails db:migrate
WARNING: This version of GitLab depends on gitlab-shell 13.25.2, but you're running 13.25.0. Please update gitlab-shell.
== 20220314154235 MigrateVulnerabilityApprovalRules: migrating ================
== 20220314154235 MigrateVulnerabilityApprovalRules: migrated (0.0512s) =======

Strategy

For the vulnerability rules belonging to a project which already has a security orchestration project:

1. a group level access token is created at the immediate group associated with the project.
2. the existing orchestration project is fetched.
3. the content of a scan policy is generated based the existing rule.
4. a commit is created (to a new branch) with the content of the scan policy into the orchestration project repository.
5. a MR is created based on the commit just created.
6. either the user who has merged the latest MR or one of the project owners is assigned to this MR.
7. the group level access token (created in the initial step) is revoked.
8. finally the vulnerability rule is deleted.

For the vulnerability rules belonging to a project which does not have a security orchestration project:

1. a group level access token is created at the immediate group associated with the project.
2. a new orchestration project is created and assigned to the main project.
3. the content of a scan policy is generated based the existing rule.
4. a commit is created (to the default branch) with the content of the scan policy into the orchestration project repository.
5. the group level access token (created in the initial step) is revoked.
6. finally the vulnerability rule report_type is updated to scan finding rule.

Users to be considered:

1. For both creating and revoking the group level access token, migration bot is used.
2. For all other operations the bot associated to access token is used. After deletion it will be displayed as a ghost bot.

Limitations:

1. Due to how tight the operations are set the usage of services for merging the MRs will fail. Therefore, as mentioned in the section above, users will be required to merge their respective MRs.
2. Projects that are not scoped under a group won't be considered as access tokens are only available at the project and group level. There might be some cases on self-hosted deployments.

MR name/description and Scan result policy name/description

Merge request title: Auto-generated Vulnerability Check Migration

Merge request description:

In GitLab 15.0, the Vulnerability Check capability has been removed and replaced with Scan Result policies.  This merge request was auto-generated with the Vulnerability Check settings that existed prior to their removal. To maintain the same security approval rules that you had in place prior to GitLab 15.0, we recommend that you merge this new Scan Result policy.

To learn more about this change, see the following links:

- [Brief video overview](Link to be added - I am planning on recording a video) of Scan Result policies.
- Documentation on [Security and compliance policies](https://docs.gitlab.com/ee/user/application_security/policies/).
- Documentation on [Scan Result policies](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html).
- [Deprecation notice](https://docs.gitlab.com/ee/update/deprecations.html#vulnerability-check) for the vulnerability check feature.

Scan result policy name: Vulnerability Check

Scan result policy description: This security approval policy was auto-generated based on the previous vulnerability check rule.

Screenshots or screen recordings

When the project doesn't have an associated orchestration project

When there is an existing orchestration project

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.