Handle multiple instances of the same scanner on one pipeline

What does this MR do and why?

In the service that marks vulnerabilities as resolved during ingestion the following steps are taken to choose which vulns to mark as resolved:

• Get all of the vulnerability reads from the project
• Filter them out to only those detected by the current scanner type (e.g. sast)
• Subtract the vuln ids just detected by the current scanner job
• Mark any that remain as resolved

This means that if the same scanner runs twice in one pipeline, say for example in different directories as per this example project, then the second scanner to run will erroneously mark all of the vulns detected by the first run as resolved.

Current implementation

In the example sequence below, 2 sast scanners run in the same pipeline. Each one detects one vulnerability.

With the current implementation, the second scan to be ingested will mark the vulns detected by the first scan as resolved.

sequenceDiagram
  participant IngestReportsService
  participant IngestReportService
  participant MarkAsResolvedService
    IngestReportsService->>IngestReportService: Ingest sast report 1
    IngestReportService->>Vulnerability: Create Vulnerability
    Vulnerability->>IngestReportService: created: [1]
    IngestReportService->>MarkAsResolvedService: Mark all sast resolved except created: [1]
    MarkAsResolvedService->>Vulnerability: Get all sast vulnerabilities
    Vulnerability->>MarkAsResolvedService: all: [1]
    MarkAsResolvedService->>MarkAsResolvedService: vulns to resolve = (all - created) = [1] - [1] = []
    MarkAsResolvedService->>MarkAsResolvedService: noop

   IngestReportsService->>IngestReportService: Ingest sast report 2
    IngestReportService->>Vulnerability: Create Vulnerability
    Vulnerability->>IngestReportService: created: [2]
    IngestReportService->>MarkAsResolvedService: Mark all sast resolved except created: [2]
    MarkAsResolvedService->>Vulnerability: Get all sast vulnerabilities
    Vulnerability->>MarkAsResolvedService: all: [1, 2]
    MarkAsResolvedService->>MarkAsResolvedService: vulns to resolve = (all - created) = [1, 2] - [2] = [1]
    MarkAsResolvedService->>MarkAsResolvedService: mark [1] as resolved

Proposed solution

This MR lifts the 'mark as resolved' step up to the IngestReportsService (note plural name) so that all of the vulns detected by a particular scan type that ran on the pipeline can be collated.

The MarkAsResolvedService now only gets called once per scanner type.

sequenceDiagram
  participant IngestReportsService
  participant IngestReportService
  participant MarkAsResolvedService
    IngestReportsService->>IngestReportService: Ingest sast report 1
    IngestReportService->>Vulnerability: Create Vulnerability
    Vulnerability->>IngestReportService: created: [1]
    IngestReportService->>IngestReportsService: Sast created[1]
    IngestReportsService->>IngestReportsService: vulns_created_by_scanner[sast] << 1
    Note right of IngestReportsService: vulns_created_by_scanner[sast] => [1]
    
    IngestReportsService->>IngestReportService: Ingest sast report 2
    IngestReportService->>Vulnerability: Create Vulnerability
    Vulnerability->>IngestReportService: created: [2]
    IngestReportService->>IngestReportsService: Sast created[2]
    IngestReportsService->>IngestReportsService: vulns_created_by_scanner[sast] << 2
    Note right of IngestReportsService: vulns_created_by_scanner[sast] => [1, 2]

    IngestReportsService->>MarkAsResolvedService: Mark all sast resolved except vulns_created_by_scanner[sast] ([1,2])
    MarkAsResolvedService->>Vulnerability: Get all sast vulnerabilities
    Vulnerability->>MarkAsResolvedService: all: [1,2]

    MarkAsResolvedService->>MarkAsResolvedService: vulns to resolve = (all - created) = [1,2] - [1,2] = []
    MarkAsResolvedService->>MarkAsResolvedService: noop

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

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.

Related to #393305 (closed)