Security sheriff: don't set M.

Sheriffbot sets M-<current stable milestone> for Security_Impact-Stable,
Security_Severity-{High,Critical}... but only if the M- is not already set.

This is the desirable pattern:
* Sheriff sets something to Security_Severity-High and Security_Impact-Stable
* Sheriff does not set M- label
* Sheriffbot sets it to the current stable milestone (e.g. M-84)
* Later, when it's fixed, Sheriffbot adds merge requests to 84, and we ship
  it in the next security fix.

We sometimes see this pattern:

* Sheriff sets something to Security_Severity-High and Security_Impact-Stable
* They also set the M- tag, but set it to the next stable milestone
* Sheriffbot therefore does not set a M- label
* Later when it's fixed, Sheriffbot does not add merge-requests to 84.
* We don't ship the fix as soon as we should.

This change calls out that the main sheriff labelling responsibility
is Impact and Severity, and most other things are set downstream by Sheriffbot.

Change-Id: Ie8d518dfa9230599f6f941de219e43382b991369
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2302739Reviewed-by: Max Moroz <mmoroz@chromium.org>
Commit-Queue: Adrian Taylor <adetaylor@chromium.org>
Cr-Commit-Position: refs/heads/master@{#789233}

docs/security/sheriff.md

@@ -261,24 +261,39 @@ the regular `Security_Severity-*` label. If the bug is not exploitable, or is
 mitigated, the V8 team will reduce the security severity (to avoid unnecessary
 risk of merging the bug into stable branches).
 
-#### Step 3. [Label, label, label](security-labels.md).
+#### Step 3. Set Impact
+
+Identify the earliest affected branch (stable, beta or head) and set either
+`Security_Impact-Stable`, `Security_Impact-Beta` or `Security_Impact-Head`.
+If you reproduced the bug with ClusterFuzz, it should do this on your behalf.
+
+#### Step 4. [Check other labels](security-labels.md).
 
 Much of Chrome's development and release process depends on bugs having the
 right labels and components. Labels and components are vitally important for
-our metrics, the visibility of bugs, and tracking our progress over time.
+merging the fix to the right releases, and ensuring reporters are credited
+correctly. They also help with metrics and visibility.
 
-Labels to **double-check** (that should already be there if the bug was filed
-using the Security template):
+Labels to **double-check** (the first two should already be there if the bug
+was filed using the Security template):
 
 * **Restrict-View-SecurityTeam**
 * **Type-Bug-Security**
 * **If the reporter wants to remain anonymous or if the bug description or
   comments contain PII**, add **Restrict-View-SecurityEmbargo**.
+* **Security_Severity** - your responsibility as Sheriff.
+* **Security_Impact** - your responsibility as Sheriff.
 
-Generally, see [the Security Labels document](security-labels.md).
+You can expect Sheriffbot to fill in lots of other labels; for example,
+the `M-` label to indicate the target milestone. It's best to allow
+Sheriffbot to add the rest, as its rules have congealed from years of
+accumulated security wisdom. See
+[the Security Labels document](security-labels.md) for an explanation of what
+the labels mean.
 
-**Ensure the comment adequately explains any status changes.** Severity,
-  milestone, and priority assignment generally require explanatory text.
+**If you change anything, add a comment which explains any status
+changes.** Severity, milestone, and priority assignment generally require
+explanatory text.
 
 * Report suspected malicious URLs to SafeBrowsing:
   * Public URL:
@@ -294,7 +309,7 @@ Generally, see [the Security Labels document](security-labels.md).
 ##### Labeling For Chrome On iOS
 
 * Reproduce using iOS device or desktop Safari.
-* Assign severity, impact, milestone, and component labels.
+* Assign severity, impact, and component labels.
 * Label **ExternalDependency**.
 * Label **Hotlist-WebKit**. This label is monitored by Apple friends.
 * File a security bug at [bugs.webkit.org](https://bugs.webkit.org), and CC