Generalize empty array for all scanners

What does this MR do and why?

Generalize empty array for all scanners for both Vulnerability-Check and scan result policies.

Related issue: #354578 (closed)

Prior to this change

Frontend relies on POST api/v4/projects/:id/approval_settings/rules with the following payload:

approvals_required: 1
group_records: []
groups: []
name: "Vulnerability-Check"
protected_branch_ids: []
remove_hidden_groups: false
report_type: "vulnerability"
rule_type: "report_approver"
scanners: ["container_scanning", "dast", "dependency_scanning", "sast", "secret_detection", "coverage_fuzzing",…]
severity_levels: ["critical"]
user_records: [{id: 22, username: "zzz", name: "zzz", state: "active",…}]
users: [22]
vulnerabilities_allowed: 0
vulnerability_states: ["newly_detected"]

Note that selecting all would cause scanners to be set to all scanners in a discrete fashion.

After persisting backend and DB reflect the above with the following:

#<ApprovalProjectRule:0x00007ff0aad795b8
 id: 49,
 created_at: Tue, 15 Mar 2022 15:39:28.463130000 UTC +00:00,
 updated_at: Tue, 15 Mar 2022 15:39:28.463130000 UTC +00:00,
 project_id: 68,
 approvals_required: 1,
 name: "Vulnerability-Check",
 rule_type: "report_approver",
 scanners: ["container_scanning", "dast", "dependency_scanning", "sast", "secret_detection", "coverage_fuzzing", "api_fuzzing"],
 vulnerabilities_allowed: 0,
 severity_levels: ["critical"],
 report_type: "vulnerability",
 vulnerability_states: ["newly_detected"],
 orchestration_policy_idx: nil>

gitlabhq_development=# select scanners from approval_project_rules where id = 49;
                                             scanners
--------------------------------------------------------------------------------------------------
 {container_scanning,dast,dependency_scanning,sast,secret_detection,coverage_fuzzing,api_fuzzing}
(1 row)

After this MR

Frontend relies on the same endpoint(api/v4/projects/:id/approval_settings/rules) with the following payload:

approvals_required: 1
group_records: []
groups: []
name: "Vulnerability-Check"
protected_branch_ids: []
remove_hidden_groups: false
report_type: "vulnerability"
rule_type: "report_approver"
scanners: []
severity_levels: ["critical"]
user_records: [{id: 22, username: "zzz", name: "zzz", state: "active",…}]
users: [22]
vulnerabilities_allowed: 0
vulnerability_states: ["newly_detected"]

Note that selecting all would cause scanners to be set to [] similar to how security reports are generated. Frontend code also handles existing records (i.e., discrete list of scanners).

After persisting, backend and DB reflect the above with the following:

=> #<ApprovalProjectRule:0x00007ffd5200ce70
 id: 49,
 created_at: Tue, 15 Mar 2022 15:39:28.463130000 UTC +00:00,
 updated_at: Tue, 15 Mar 2022 16:10:11.146030000 UTC +00:00,
 project_id: 68,
 approvals_required: 1,
 name: "Vulnerability-Check",
 rule_type: "report_approver",
 scanners: [],
 vulnerabilities_allowed: 0,
 severity_levels: ["critical"],
 report_type: "vulnerability",
 vulnerability_states: ["newly_detected"],
 orchestration_policy_idx: nil>

select scanners from approval_project_rules where id = 49;
 scanners
----------
 {}
(1 row)

Screenshots or screen recordings

Vulnerability-Check

Backend

pry(main)> Project.find(5).approval_rules.first
=> #<ApprovalProjectRule:0x00007fccc4508a00
 id: 40,
 created_at: Thu, 10 Mar 2022 20:19:25.810805000 UTC +00:00,
 updated_at: Thu, 10 Mar 2022 22:02:22.664139000 UTC +00:00,
 project_id: 5,
 approvals_required: 1,
 name: "Vulnerability-Check",
 rule_type: "report_approver",
 scanners: [],
 vulnerabilities_allowed: 0,
 severity_levels: ["critical"],
 report_type: "vulnerability",
 vulnerability_states: ["newly_detected"],
 orchestration_policy_idx: nil>

Frontend

Scan result policy

YAML/RULE

How to set up and validate locally

1. Enable scan_result_policy feature flag (if you haven't pulled master for a while)
2. Create a security project as described in the docs
3. Create a new scan result policy with the project owner

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.