Adjust `Security::StoreReportService` to look up findings using UUIDv5, attempt 2

What does this MR do?

Adjusts the logic present in Security::StoreReportService#create_or_find_vulnerability_finding to match the following flowchart so that we use UUIDv5 whenever possible.

Query details

Selecting a Vulnerabilities::Finding by UUID

https://postgres.ai/console/gitlab/gitlab-production-tunnel/sessions/1758/commands/5930

Sample query

SELECT * FROM vulnerability_occurrences WHERE project_id = 23762767 AND uuid = '6892fc62-ed64-5494-bb8d-83e418f9deda' LIMIT 1;

Full execution plan

 Limit  (cost=0.56..3.58 rows=1 width=1131) (actual time=15.098..15.099 rows=0 loops=1)
   Buffers: shared read=4
   I/O Timings: read=15.031
   ->  Index Scan using index_vulnerability_occurrences_on_uuid on public.vulnerability_occurrences  (cost=0.56..3.58 rows=1 width=1131) (actual time=15.096..15.097 rows=0 loops=1)
         Index Cond: ((vulnerability_occurrences.uuid)::text = '6892fc62-ed64-5494-bb8d-83e418f9deda'::text)
         Filter: (vulnerability_occurrences.project_id = 23762767)
         Rows Removed by Filter: 0
         Buffers: shared read=4
         I/O Timings: read=15.031

Summary

Time: 15.297 ms
  - planning: 0.167 ms
  - execution: 15.130 ms
    - I/O read: 15.031 ms
    - I/O write: N/A

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

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• [-] Tested in all supported browsers
• [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• [-] Label as security and @ mention @gitlab-com/gl-security/appsec
• [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• [-] Security reports checked/validated by a reviewer from the AppSec team

Related to #292236 (closed)

ee/app/services/security/store_report_service.rb

@@ -85,7+85,7 @@
 
         # If there's no Finding then we're dealing with one of two cases:
         # 1. The Finding is a new one
         # 2. The Finding is already saved but has UUIDv4
         unless vulnerability_finding
           vulnerability_finding = project.vulnerability_findings
             .create_with(create_params)
@@ -96,7+96,7 @@
         vulnerability_finding.save!
         vulnerability_finding
       rescue ActiveRecord::RecordNotUnique => e
-        Gitlab::ErrorTracking.track_and_raise_exception(e, find_params: find_params, uuid: finding.uuid)
+        # This might happen if we're processing another report in parallel and it finds the same Finding
+        # faster. In that case we need to perform the lookup again
 
-        vulnerability_finding
+        by_uuid = project.vulnerability_findings.reset.find_by(uuid: finding.uuid)
+        return by_uuid if by_uuid
+
+        by_find_params = project.vulnerability_findings.reset.find_by(find_params)
+        return by_find_params if by_find_params
+
+        Gitlab::ErrorTracking.track_and_raise_exception(e, find_params: find_params, uuid: finding.uuid)
       rescue ActiveRecord::RecordInvalid => e
         Gitlab::ErrorTracking.track_and_raise_exception(e, create_params: create_params&.dig(:raw_metadata))
       end