Explore ways of tracking state changes of a Vulnerability

High-level problem statement

How do we track changes to the Vulnerability state with comments?

How did we discover the problem?

During work on #292636 (closed) it came to our attention that we have no sane way of extending GraphQL mutations for manipulating the state of a given Vulnerability to account for user comments.

Current approach

Currently we have four possible states for a Vulnerability:

1. Detected – Vulnerability#state is detected; there's no Vulnerabilities::Feedback that dismisses the vulnerability OR no Vulnerabilities::Feedback that ties the Vulnerability to an Issue
2. Dismissed – Vulnerability#state is dismissed; there's a Vulnerabilities::Feedback that dismisses the Vulnerability
3. Confirmed – Vulnerability#state is confirmed OR there's Vulnerabilities::Feedback which ties the Vulnerability::Finding to an Issue. We also rely on the fact that there should be no Vulnerabilities::Feedback that dismisses the issue
4. Resolved – Vulnerability#state is resolved

Possible solutions

Extend Vulnerabilities::Feedback#feedback_type to account for confirmation and resolution

The simplest solution in which we create additional values for vulnerability confirmation and resolution state. While I wrote the simplest I am not entirely convinced that is the simplest solution since we would have to create additional rules about how our system works.

If we extend Vulnerabilities::Feedback to account for confirmation and resolution the we would have to make sure we have a Vulnerabilities::Feedback record for every Vulnerability that's either confirmed or resolved.

Pros:

• Kind of ties into the existing system
• Doesn't require that much backend work

Cons:

• Lots of database work
• This model will actually have two responsibilities: tracking Vulnerability state changes AND allowing us to take action of Vulnerability::Findings that did not get promoted to a Vulnerability yet

Track the changes in a different model

At this point I'm tempted to delegate this to another model – let's name it VulnerabilityStateChange whose only concern would be tracking state changes for a given Vulnerability

Pros:

• Wouldn't affect Vulnerabilities::Feedback role
• We can add as many states as we want without touching the vulnerabilites table
• Would allow us to retain a clear history of Vulnerability state changes along with reasons for said changes

Cons:

• backend and database work

Use Notable on Vulnerability

Here's how that looks like https://gitlab.com/gitlab-org/gitlab/-/snippets/2084288

Pros:

• Relatively simple

Cons:

• It's more of a free-form comment rather than a state tracking system