Mark vulnerabilities as no longer detected on the default branch when running Dependency Scanning with SBOM

Why are we doing this work

Now that we've completed SBOM-based dependency scanning findings for def... (&8026 - closed), we can execute a full Dependency Scanning security scan of a project when ingesting the CycloneDX report artifact (aka CVS on SBOM changes for DS).

When doing this, we should also update all vulnerabilities that were previously reported on the default branch but are no longer detected in this new scan. This process is already in place when ingesting security scanning results from the security report artifacts, by calling the Security::Ingestion::MarkAsResolvedService.

We should adjust this service to be able to call it after CVS on SBOM changes.

Relevant links

Non-functional requirements

• Documentation: None
• Feature flag: mark_resolved_vulnerabilities_with_sbom_scans(gitlab_com_derisk type). The rollout issue is: [Feature flag] Rollout of `mark_resolved_vulner... (#515627 - closed) • Olivier Gonzalez, Oscar Tovar • 17.10 • At risk
• Performance: None
• Testing: Verify when mixing multiple SBOM reports of different source type (DS vs CS).

Implementation plan

• Adjust Sbom::CreateVulnerabilitiesService execution to collect the ids of the ingested vulnerabilities. This will require to refactor Gitlab::VulnerabilityScanning::AdvisoryUtils.
• Call the Security::Ingestion::MarkAsResolvedService with the "Gitlab sbom Vulnerability Scanner" scanner record for this project and the ingested ids
• Modify the Security::Ingestion::MarkAsResolvedService to consider the vulnerablity type (report_type) when scoping records to be checked.

⚠️ The Sbom::CreateVulnerabilitiesService service currently delegates actual vulnerability creation to underlying logic shared with CVS on Advisory change. Though, the later has a different workflow (it runs againts many different projects, for th same advisory) and should not be triggering the MarkAsResolvedService. Indeed, this workflow only create vulnerability for a specific advisory and doesn't do a full scan. Triggering MarkAsResolvedService in this situation will likely mark all vulnerabilities as resolved but this one we just created.

Verification steps

See !179119 (merged)