Implement a security report schema deprecation mechanism

Why are we doing this work?

In order to enforce validation of security report schemas we need a mechanism to specify which versions are supported and which ones are deprecated.

Implementation plan

1. Extend lib/gitlab/ci/parsers/security/validators/schema_validator.rb with SUPPORTED_VERSIONS and DEPRECATED_VERSIONS hashes

SUPPORTED_VERSIONS = {
  sast: %w[14.0.0 14.1.0],
  dast: %w[13.0.0 14.0.0],
  ...
}

DEPRECATED_VERSIONS = {
  sast: %w[13.0.0 13.1.0]
  dast: %w[12.9.0 12.10.0]
  ...
}

2. Extend specs to check for the file presence on disk and that the versions declared match the ones that are supported/deprecated

Things to consider if the implementation plan doesn't scale well enough

In the scenario when we have a big number of schemas to deprecate and support we might have to consider a different approach on how to maintain the list of schemas:

1. Split the schema files into deprecated/*.json and supported/*.json and have the model automatically populate the values
2. Create a Rake task to generate the constants (similar to GraphQL docs)
3. Resolve dependency versions using (in)equality operators

Testing

• Ensure the spec contains validations for supported version, deprecated version and unsupported version for each analyser type
• Ensure MR is reviewed by counterpart SET