Auto-nominate for backport a pull request fixing a regression

[apiraino]

From #1184:

We should nominate PRs for backport if any of the following are true:

1. Description mentions a issue which is labeled as [regression]
2. Description mentions a issue which is milestoned with the beta version number

---

This patch implements point (1) and adds a check when a new PR is opened. The new backport.rs handler tries to figure to out if a PR should be nominated for backport.

This handler is enabled by adding a new [backport] config item. The format allows multiple instances of the config so teams can handle backports as they wish.

# "foo" is just to disambiguate multiple instances of this config
[backport.foo]
# The pull request MUST have one of these labels
team_labels = ["T-compiler"]
# The regression MUST have this label
needs_label = "regression-from-stable-to-beta"
# if the above conditions matches, the PR will receive these labels
add_labels = ["beta-nominated"]

[backport.bar]
team_labels = ["T-compiler"]
needs_label = "regression-from-stable-to-stable"
add_labels = ["beta-nominated", "stable-nominated"]

[backport.baz]
team_labels = ["T-libs", "T-libs-api"]
needs_label = "regression-from-stable-to-stable"
add_labels = ["stable-nominated"]

The workflow that models the decision to add the backport label is:

0. Someone files a regression #123, with a t-label (ex. "T-compiler")
1. Contributor opens PR #456, adds comment "Fixes #123"
2. triagebot receives the event "new PR"
3. triagebot parses the opening comment and retrieves originating regression(s)
   3a. checks if PR has the required team labels (reads from team_labels), loads the appropriate config
   3b. checks if issue has a regression-from-* label (reads from needs_label)
   3c. checks the P-label of the regression, discard P-low and P-medium regressions
4. triagebot adds backport label(s) to PR Implement the prioritize command #456 (reads from add_labels)

TODOs

Situations not yet handled where this handler should trigger as well:

• PR is opened without a T-label (can that happen? or is that automatically applied?), user adds a T-label to the PR later
• The regression receives a P-label when the PR fixing it already exists
• The expected marker text ("Fixes, resolves, etc.") is added later
• probably other cases ...

This work supersedes #1380 (Important: before merge this commit should be Co-authored¹)

r?

Footnotes

1. Not doing now to avoid spamming the original author with multiple forced git push 🙂 ↩