Bump major version of Container Scanning analyzer
<!--
Implementation issues are used break-up a large piece of work into small, discrete tasks that can
move independently through the build workflow steps. They're typically used to populate a Feature
Epic. Once created, an implementation issue is usually refined in order to populate and review the
implementation plan and weight.
Example workflow: https://about.gitlab.com/handbook/engineering/development/threat-management/planning/diagram.html#plan
-->
## Why are we doing this work
All the [pinned analyzer versions have been deprecated](https://docs.gitlab.com/ee/update/deprecations#secure-and-protect-analyzer-major-version-update).
This means we need to:
1. bump the major version on the CS analyzer in %15.0.
1. maintain a pipeline for the current major version for at least 2 years to:
1. Keep updating the advisory database in the images; and
1. Be able to release updates should we need to backport fixes
~~In scope for this issue are items 1 and 1.1 above. Item 1.2 can be done when and if we need to backport anything to the previous version.~~ Ended-up doing all items, so this ended-up being more like a weight:3 instead of the original 2.
<!--
A brief explanation of the why, not the what or how. Assume the reader doesn't know the
background and won't have time to dig-up information from comment threads.
-->
## Relevant links
<!--
Information that the developer might need to refer to when implementing the issue.
- [Design Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/<id>)
- [Design 1](https://gitlab.com/gitlab-org/gitlab/-/issues/<id>/designs/<image>.png)
- [Design 2](https://gitlab.com/gitlab-org/gitlab/-/issues/<id>/designs/<image>.png)
- [Similar implementation](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/<id>)
-->
## Non-functional requirements
As per the [notice](https://docs.gitlab.com/ee/update/deprecations#secure-and-protect-analyzer-major-version-update):
> Users of GitLab 12.0-14.10 will continue to experience analyzer updates as normal until the release of GitLab 15.0, following which all newly fixed bugs and newly released features in the new major versions of the analyzers will not be available in the deprecated versions because we do not backport bugs and new features as per our maintenance policy.
>
> As required security patches will be backported within the latest 3 minor releases.
Also, per our [statement of support](https://about.gitlab.com/support/statement-of-support/#version-support):
> Unless otherwise specified in your support contract, we support the current major version and previous two major versions only
<!--
Add details for required items and delete others.
-->
- [ ] Documentation:
- [x] Image versions and examples in https://docs.gitlab.com/ee/user/application_security/container_scanning/
- [ ] Feature flag:
- [ ] Performance:
- [ ] Testing:
## Implementation plan
- [x] Bump the analyzer version to `5.0.0`.
- [x] Update the [CI template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml) to use `CS_ANALYZER_IMAGE: registry.gitlab.com/security-products/container-scanning:5`
- [x] Create a `v4.x` branch with the same protections as the default branch. This will be used in the future when we need to backport changes to v4.
- [x] Add or update the schedule that triggers DB updates to include all major versions listed in `TRIGGER_DB_UPDATE_FOR_MAJOR_VERSIONS`.
<!--
Steps and the parts of the code that will need to get updated. The plan can also
call-out responsibilities for other team members or teams.
e.g.:
- [ ] ~frontend Step 1
- [ ] `@person` Step 1a
- [ ] ~frontend Step 2
-->
<!--
Workflow and other relevant labels
# ~"group::" ~"Category:" ~"GitLab Ultimate"
Other settings you might want to include when creating the issue.
# /assign @
# /epic &
-->
## Verification steps
<!--
Add verification steps to help GitLab team members test the implementation. This is particularly useful
during the MR review and the ~"workflow::verification" step. You may not know exactly what the
verification steps should be during issue refinement, so you can always come back later to add
them.
1. Check-out the corresponding branch
1. ...
1. Profit!
-->
issue