Ensure Vulnerabilities to be created as confidential - backstage

What does this MR do?

This MR is a part of the backstage implementation of the foundation for the new feature: Standalone Vulnerability Objects. It was extracted from the initial the backstage implementation issue into a separate issue.

The idea of this MR is to have new Vulnerabilities as confidential by default. This is similar to the access model for confidential Issues with the following differences:

• minimal access level required to view the Vulnerabilities is Developer (see the upcoming permissions entry in the Project Permissions table)
• Vulnerabilities are always confidential as for now; there is no way to make them "public"

Also, this MR contains refactoring of the AccessMatchers module (renamed to AccessMatchersForSystemTest) and enhancing it to be used for request specs (AccessMatchersForRequest) and business logic permissions' specs (AccessMatchers).

Documentation is not part of this MR because the entire feature is covered by the feature flag and is in the MVC stage. Documentation for the API is created in the form of documentation stubs and will be actualized and made public when the feature flag is removed.

Changelog entry is not part of this MR for similar reasons. The "umbrella" changelog entry for the entire Standalone Vulnerabilities feature will be added when the feature flag is removed.

Additional TODO items

• Revamp !19819 (merged) specs using new AccessMatchers module after it is merged and rebased

Does this MR meet the acceptance criteria?

Conformity

• [-] Changelog entry | Will be added upon feature flag removal
• [-] Documentation created/updated or follow-up review issue created | Will be actualized later
• 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