Clarify the milestone requirements for security MRs

Security releases happen after the main monthly release, so the first
"backport" will actually be for the most recent release.

This frequently causes confusion and authors end up creating an
unnecessary backport for an older release, instead of the latest one.

This is explained in the [security workflow documentation][1], but we
should also clarify this in the security issue and merge request
templates.

We don't really need a milestone on the MR merging into `master`, so
we also change the Danger rules to not require one.

[1]: https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md#security-merge-requests

.gitlab/issue_templates/Security developer workflow.md

@@ -29,6 +29,7 @@ After your merge request has been approved according to our [approval guidelines
 ## Backports
 
 - [ ] Once the MR is ready to be merged, create MRs targeting the latest 3 stable branches
+   * The 3 stable branches correspond to the versions in the title of the Security Release Tracking Issue.
    * At this point, it might be easy to squash the commits from the MR into one
    * You can use the script `bin/secpick` instead of the following steps, to help you cherry-picking. See the [secpick documentation]
 - [ ] Create each MR targeting the stable branch `X-Y-stable`, using the [Security Release merge request template].

.gitlab/merge_request_templates/Security Release.md

@@ -14,7 +14,6 @@ See [the general developer security release guidelines](https://gitlab.com/gitla
 
 - [ ] **On "Related issues" section, write down the [GitLab Security] issue it belongs to (i.e. `Related to <issue_id>`).**
 - [ ] Merge request targets `master`, or a versioned stable branch (`X-Y-stable-ee`).
-- [ ] Milestone is set for the version this merge request applies to. A closed milestone can be assigned via [quick actions].
 - [ ] Title of this merge request is the same as for all backports.
 - [ ] A [CHANGELOG entry] has been included, with `Changelog` trailer set to `security`.
 - [ ] For the MR targeting `master`:
@@ -24,6 +23,7 @@ See [the general developer security release guidelines](https://gitlab.com/gitla
     - Please see the security release [Code reviews and Approvals](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md#code-reviews-and-approvals) documentation for details on which AppSec team member to ping for approval.
     - Trigger the [`package-and-qa` build]. The docker image generated will be used by the AppSec engineer to validate the security vulnerability has been remediated.
 - [ ] For a backport MR targeting a versioned stable branch (`X-Y-stable-ee`)
+  - [ ] Milestone is set to the version this backport applies to. A closed milestone can be assigned via [quick actions].
   - [ ] Ensure it's approved by a maintainer.
 
 **Note:** Reviewer/maintainer should not be a Release Manager

danger/metadata/Dangerfile

@@ -2,6 +2,8 @@
 
 # rubocop:disable Style/SignalException
 
+DEFAULT_BRANCH = 'master'
+
 THROUGHPUT_LABELS = [
   'Community contribution',
   'security',
@@ -29,12 +31,12 @@ end
 
 has_milestone = !gitlab.mr_json["milestone"].nil?
 
-unless has_milestone
+unless has_milestone || (helper.security_mr? && gitlab.branch_for_base == DEFAULT_BRANCH)
   warn "This merge request does not refer to an existing milestone.", sticky: false
 end
 
 has_pick_into_stable_label = gitlab.mr_labels.find { |label| label.start_with?('Pick into') }
 
-if gitlab.branch_for_base != "master" && !has_pick_into_stable_label && !helper.security_mr?
-  warn "Most of the time, merge requests should target `master`. Otherwise, please set the relevant `Pick into X.Y` label."
+if gitlab.branch_for_base != DEFAULT_BRANCH && !has_pick_into_stable_label && !helper.security_mr?
+  warn "Most of the time, merge requests should target `#{DEFAULT_BRANCH}`. Otherwise, please set the relevant `Pick into X.Y` label."
 end