Respond with 304 Not Modified if Vulnerability is already dismissed

What does this MR do?

A follow-up after Dismiss Vulnerability API operation in the spirit of starring a Project: there's no need to invoke backend logic and try to dismiss a Vulnerability again if it's already dismissed.

Currently, there's no separate dismissed state for a Vulnerability. closed state represents both dismissed and resolved vulnerabilities (see computed state of a Vulnerability Finding). Therefore, the closed state is enough to determine whether we should do any dismissal action or not.

The terminology and relationships between Vulnerabilities and other entities are described in the Dismiss Vulnerability MR and here.

There's no changelog entry because this is the API for the MVC changes yet to come and it's covered by a disabled feature flag.

Documentation will arrive in the form of stubs not yet exposed to use for the same reason as the above item.

Does this MR meet the acceptance criteria?

Conformity

• [-] Changelog entry
• [-] Documentation created/updated or follow-up review issue created
• Code review guidelines
• Merge request performance guidelines
• Style guides
• [-] Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• [-] Tested in all supported browsers

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• [-] Label as security and @ mention @gitlab-com/gl-security/appsec
• [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team