Refactor query for Vulnerabilities::Feedback associated to a Vulnerabilities::Occurrence
Summary
Follow up: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/15553#note_209480757
We retrieve vulnerabilities for the security dashboard, as well as feedback for each of them. There is no primary key relationship or ActiveRecord association between Vulnerabilities::Occurrence and Vulnerabilities::Feedback, so feedback belonging to a vulnerability is fetched using the BatchLoader and matching on fingerprints.
When a vulnerability is dismissed, it has one feedback with a feedback_type: 0 (or 'dismissal'). When using the filter hide_dismissed on the security dashboard, we need to retrieve all vulnerabilities that do not have a feedback with this value. Without a PK relationship or AR association, there's no obvious way to write a query that returns an AR collection. Instead we have to reject dismissed Vulnerabilities::Occurrence in memory by checking for the presence of a feedback with that type. We can't do this in the Vulnerabilities::Finder with the other filters, because an AR collection is expected in Vulnerabilities::Actions and in controllers for ordering and pagination.
Improvements
Having one filter for the security dashboard in a different class from the others is not best practice and can lead to unexpected behavior. Similarly, consistently using AR collections instead of ruby enumerables will reduce the number of potential regressions. We may also see performance improvements.
Risks
This will need to be balanced with the transition to Vulnerabilities as first-class objects.