Manually update vulnerability_reads with upsert service

What does this MR do and why?

This MR continues the work from !208297 (merged) by manually updating vulnerability_reads records now that the SQL database trigger has been turned off.

With the database trigger feature flag being disabled, vulnerability_reads records need to be manually updated at the application level. This MR:

1. Creates a new upsert utility service for vulnerability reads (Vulnerabilities::Reads::UpsertService)
2. Makes the upsert service capable of handling bulk upserts
3. Refactors and modifies files to use the common Vulnerabilities::Reads::UpsertService
4. Changes manual updates throughout the codebase to use this utility service

Background

The original MR !208297 (merged) was merged but had to be reverted (see !212452 (merged)) due to a master:foss-broken issue. The problem was that a scope (pluck_distinct_project_ids) was used in the Community Edition (CE) of GitLab but was only present in the Enterprise Edition (EE), causing FOSS builds to break.

This MR addresses that issue by ensuring all necessary code is available in both CE and EE contexts, while maintaining the same functionality for manual vulnerability reads updates.

How?

This MR builds upon the infrastructure established in !208297 (merged) and refined in !212568 (closed):

Infrastructure

• Utilizes feature flag transaction helper methods from SecApplicationRecord:
  • feature_flagged_transaction_for(projects) - wraps transactions with feature flag passing
  • db_trigger_flag_not_set? - checks if feature flag is set
  • pass_feature_flag_to_vuln_reads_db_trigger(projects) - passes flag to DB trigger
• Leverages the EnforceVulnerabilityReadDbTriggerFf concern to enforce feature flag usage in transactions
• Ensures CE/EE compatibility by properly scoping EE-only features

Model Extensions

• Extended Vulnerability, Vulnerabilities::Finding, Vulnerabilities::MergeRequestLink, and Vulnerabilities::Read models with enforcement concern
• Added necessary scopes (like pluck_distinct_project_ids) in appropriate CE/EE contexts

Service Updates

Updates vulnerability services to use the new upsert service for manual vulnerability_reads updates, ensuring consistency across:

• Vulnerabilities::Archival::Restoration::RestoreBatchService
• Vulnerabilities::Archival::ArchiveBatchService
• Vulnerabilities::BaseService
• Vulnerabilities::BaseStateTransitionService
• Vulnerabilities::BulkDismissService
• Vulnerabilities::BulkSeverityOverrideService
• Vulnerabilities::CreateService
• Vulnerabilities::FindOrCreateFromSecurityFindingService
• Vulnerabilities::ManuallyCreateService
• Vulnerabilities::AutoResolveService
• Vulnerabilities::Removal::RemoveFromProjectService
• Vulnerabilities::Findings::FindOrCreateFromSecurityFindingService
• Vulnerabilities::Reads::UpsertService
• Import::DirectReassignService (with special handling for Vulnerability models)

This ensures that we're safely managing vulnerability reads at the application level while maintaining the ability to track that all necessary updates are being performed, and that the implementation works correctly in both CE and EE environments.

References

Related to:

• !208297 (merged) (Original enforcement MR - merged)
• !212452 (merged) (Revert MR due to FOSS breakage)
• !212568 (closed) (Additional implementation details)
• #580521 (Reinstate issue)

How to set up and validate locally

1. Ensure the database trigger feature flag is disabled
2. Perform operations that create or update vulnerabilities
3. Verify that vulnerability_reads records are correctly created/updated via the upsert service
4. Run the test suite to ensure all vulnerability read updates are properly handled
5. Verify FOSS compatibility by running tests in CE context

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.