Add project rules based on scan result policies

What does this MR do and why?

Add project rules based on scan result policies into the logic for synchronizing the approval of merge request approval rules.

Related issue: #339272 (closed)

It fixes a small issue related to code coverage throwing NoMethodError as described in #342591 (closed)

This MR finishes the cycle of creation of approval rules from the scan result policies. Scan result policies will be added to the existing scan execution policies. An example of the scan result policies can be found here.

In this initial MR the scan_result_policy and its respective feature flag has been added.

This second MR puts the creation of project approval rules from the scan result policy and extends the creation of merge approval rules from project approval rules.

This is the epic which contains all these issues.

Some screenshots have been added for context.

Screenshots or screen recordings

Main functionality will be similar to Vulnerability-check

More details of Vulnerability-Check

Setting up the policy orchestration project

Example of a policy orchestration file

Approval rules within the MR widget

Query(Scope only)

For the scope !70633 (diffs)

explain SELECT DISTINCT "approval_project_rules"."scanners" FROM "approval_project_rules" WHERE "approval_project_rules"."report_type" = 4

Session: 7054 Plan with execution:

 Unique  (cost=3.24..3.24 rows=1 width=114) (actual time=2.148..2.150 rows=0 loops=1)
   Buffers: shared hit=8 read=3
   I/O Timings: read=2.058 write=0.000
   ->  Sort  (cost=3.24..3.24 rows=1 width=114) (actual time=2.148..2.149 rows=0 loops=1)
         Sort Key: approval_project_rules.scanners
         Sort Method: quicksort  Memory: 25kB
         Buffers: shared hit=8 read=3
    
[...SKIP...]

Full execution plan (The text in the preview above has been cut) Other artifacts are provided in the thread Recommendations: ✅ Looks good Summary:

Time: 3.189 ms
  - planning: 0.957 ms
  - execution: 2.232 ms
    - I/O read: 2.058 ms
    - I/O write: 0.000 ms

Shared buffers:
  - hits: 8 (~64.00 KiB) from the buffer pool
  - reads: 3 (~24.00 KiB) from the OS file cache, including disk I/O
  - dirtied: 0
  - writes: 0

Details and visualization: https://postgres.ai/console/gitlab/gitlab-production-tunnel-pg12/sessions/7054/commands/24917. (edited) ✅

Query plan (with project)

explain SELECT DISTINCT "approval_project_rules"."scanners" FROM "approval_project_rules" WHERE "approval_project_rules"."report_type" = 4 and "approval_project_rules"."project_id" = 29108710

Session: 7080 Plan with execution:

 Unique  (cost=3.45..3.46 rows=1 width=114) (actual time=2.201..2.203 rows=0 loops=1)
   Buffers: shared hit=8 read=3
   I/O Timings: read=2.131 write=0.000
   ->  Sort  (cost=3.45..3.46 rows=1 width=114) (actual time=2.201..2.202 rows=0 loops=1)
         Sort Key: approval_project_rules.scanners
         Sort Method: quicksort  Memory: 25kB
         Buffers: shared hit=8 read=3
    
[...SKIP...]

Full execution plan (The text in the preview above has been cut) Other artifacts are provided in the thread Recommendations: ✅ Looks good Summary:

Time: 3.142 ms
  - planning: 0.867 ms
  - execution: 2.275 ms
    - I/O read: 2.131 ms
    - I/O write: 0.000 ms

Shared buffers:
  - hits: 8 (~64.00 KiB) from the buffer pool
  - reads: 3 (~24.00 KiB) from the OS file cache, including disk I/O
  - dirtied: 0
  - writes: 0

Details and visualization: https://postgres.ai/console/gitlab/gitlab-production-tunnel-pg12/sessions/7080/commands/25033. (edited) ✅

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.