Make CVS pass affected SBOM occurrences to security ingestion

Problem to solve

As part of Use database for project dependency list (&8293 - closed), groupthreat insights is introducing sbom_occurrence_vulnerabilities, a new DB table that tracks relations between vulnerabilities and SBoM occurrences. The is motivated by performance issues impacting the Dependency List.

However, the complexity of the code could be reduced.

• Vulnerability ingestion has to infer the relation b/w vulnerabilities and SBoM occurrences even though this relation is directly available to Continuous Vulnerability Scanning (CVS). See https://gitlab.com/gitlab-org/gitlab/-/blob/e3f10b3e9eb990f02e1688754bca109864bf9fc0/ee/lib/gitlab/vulnerability_scanning/advisory_scanner.rb#L36
• CVS generates full-fleshed vulnerabilities similar to the ones ingested from the Dependency Scanning reports even though most fields could be inferred from the affected SBoM occurrence.

Further details

Quoting @bwill on the need for the sbom_occurrence_vulnerabilities table:

Showing many vulnerabilities for many dependencies on the dependency list isn't practical from a performance standpoint, so what we are doing is showing only the vulnerability counts and then asynchronously loading occurrence.vulnerabilities for a single dependency when the user clicks to see the vulnerability details. This relationship is intended to be accessed for one dependency at a time and won't scale for multiple at once.

Right now CVS relies on the IngestCvsSliceService which is similar to the IngestReportSliceService. IngestCvsSliceService is optimized to ingest vulnerabilities affecting a large number of projects. It receives a FindingMap that doesn't reference the Sbom::Occurrence model.

Proposal

Change the contract b/w CVS and security ingestion:

1. A first step would to add the sbom_occurrence_id to the finding map passed to the IngestCvsSliceService. Vulnerability ingestion would change to directly store that relation in the sbom_occurrence_vulnerabilities table.
2. A possible second step is to make CVS only pass affected SBoM occurrences and generic vulnerabilities without repeating the information that's already available through SBoM occurrences. In particular, it would need to pass the location details. It's a bigger change that would extract some of the complexity out of CVS matching.

cc @zmartins @gonzoyumo @thiagocsf