Enforce passing of database trigger feature flag for Vulnerability Read Creation

What does this MR do and why?

In the interest of easier reviewability, this MR takes the responsibility of enforcing that the database trigger for vulnerability_reads creation from !199517 (merged) so that that one can focus on the new vulnerability read upsert service in isolation.

This MR ensures that we're safely passing the FF to the DB trigger everywhere applicable by causing tests to fail if the flag is not found in the transaction config of classes applicable to the creation of Vulnerability Reads.

How?

Essentially we wanted to make sure that modifications to models that then impact the data in the corresponding vulnerability_read record will set the feature flag for the database trigger so that we can identify that we have successfully covered all our bases at the application level. Our spec failing due to records not being updated would then expose services that have not been appropriately accounted for.

This will additionally remain in the codebase until the triggers are removed so that any changes in the meantime will force adding the FF, and thus demonstrate missing vulnerability read updates if applicable.

References

Screenshots or screen recordings

Before	After

How to set up and validate locally

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.