Add PR "rollups"

[brson]

Rust frequently has a dozen small PR's in the queue and we are near our throughput limit for serially landing them, so we frequently "rollup" multiple branches into one PR. bors should have a simple way to do this automatically, maybe r+ rollup.

cc @alexcrichton

[Gankra]

Notes from discussion today:

Would like a rollup and try directive.

try would have bors test out the PR on the try branch. This is useful for quick-checking human-made rollups, which often fail, without blocking the queue.

rollup would mark the PR as a candidate for an automatic rollup. This would add an implicit p=-1 to the PR, meaning it will only be merged normally if all other PRs are also p=-1. Automatic rollups should occur once per day.

Example usage:

---

Someone makes a manual rollup. You accept it with the following directive:

r+ try p=10

This will have bors run the branch under try first, and only on success place it in the queue as accepted, with p=10.

---

Someone makes a documentation change that is expected to trivially pass and not conflict with anything else. It would be a waste of resources to run the full test suite on just this patch in isolation. You accept it with the following directive.

r+ rollup

This marks the PR as p=-1, and it will be merged at the end of the day with all other rollup PRs into a single job with p=1.

---

CC @cmr @brson

[frewsxcv]

Someone makes a documentation change that is expected to trivially pass

If for whatever reason a merge conflict does happen, should it avoid the rollup altogether? Possibly try different combinations of commits?

[Gankra]

This is a good question. In my head I picture something like: merge commits in order, if one causes a conflict, drop it and continue. Best effort rollup.

[Gankra]

As a first draft you could have it abort, though.

[larsbergstrom]

From Servo's point of view, we are planning toadd @bors: try so that you could do so without implying r+.

One important bit is that try processing should always happen after any r+ or retry processing (due to the laggy polling-based nature of bors, at least in Servo's branch of it).