Simplify association of vulnerability feedback to vulnerability occurrences

Summary

We currently associate vulnerability_occurrences to vulnerability_feedback via each table's project_fingerprint field. The fingerprints are stored as strings in the feedback table and as binary in the occurrences table.

This makes it expensive to fetch associated records, since it requires either encoding/decoding the fields in SQL or bringing the records into Ruby.

Improvements

The security dashboards and pipeline and MR vulnerability widgets all rely on associating occurrences with their feedback. Refactoring will simplify the logic behind those features and possibly lead to performance gains.

Risks

The major risk is breaking the association between an occurrence and its feedback.

Involved components

Vulnerabilities::Feedback, Vulnerabilities::Occurrence, their Finders, and their DB tables.

Historical context

The mismatch between fingerprint field type is because the feedback table was created when we were still using MySQL, and MySQL doesn't support partial indices.