Apply "enormous changes" rules to pre-commit content rules too

Summary:
Fixes T4276. This adds "Change is enormous" to pre-commit content rules so we can, e.g., just reject these and not worry about them elsewhere.

Also, use the same numeric limits across the mechanisms so there's a consistent definition of an "enormous" changeset.

Test Plan:
  - Set enormous limit to 15 bytes, pushed some changes, got blocked by a rule.
  - Set it back, pushed OK.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4276

Differential Revision: https://secure.phabricator.com/D7887
Rename "Apply build plans" to "Run build plans" in Herald

Summary: "Run" is clearer than "Apply". This has already been changed in Harbormaster itself.

Test Plan: used eyeballs

Reviewers: btrahan, zeeg

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D7889
Adjust transformed URI in CSS

Summary: This one CSS file has a pre-transformed URI in it, just use a raw resource name. The tranform pipeline will fix it (and this URI is no longer correct).

Test Plan: Loaded some pages.

Reviewers: btrahan, chad

Reviewed By: chad

CC: chad, aran

Differential Revision: https://secure.phabricator.com/D7895
Simplify adding new database patches

Summary:
Currently, to add new migration patches you need to:

  - Add a file to `resources/sql/patches/`; then
  - add an entry to `src/infrastructure/storage/blahblah/BlahBlahBlah.php`.

The second step isn't actually necessary, and we've been using this system for a long time without any issues arising.

Instead of requiring manual adjustments to the patch list, infer the patch specifications from the files on disk so you don't need to do step 2.

Also, simplify the existing data, which can //mostly// be derived from patch names. There are a few exceptions/errors, noted inline, which are preserved for compatibility.

Test Plan:
  - For the new genration of `name` and `type`, I added code to check that the old and new values were the same before converting. This caught the two inline exceptions ("emailtableport", "drydockresouces").
  - Added new patches to `autopatches/` and ran `bin/storage status` to verify they got picked up correctly.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D7894
Add mailKey to macros

Summary:
If you have private replies on and a Macro reply handler set, we try to access `getMailKey()` and fail. See P1039 for a trace.

(Thanks to @Korvin for picking this up.)

Test Plan: Set configuration, repro'd the exception, applied the patch, then disabled/enabled a macro.

Reviewers: btrahan

Reviewed By: btrahan

CC: Korvin, aran

Differential Revision: https://secure.phabricator.com/D7896
Split Harbormaster workers apart so build steps can run in parallel

Summary:
Ref T1049. Currently, the Harbormaster worker looks like this:

  foreach (step) {
    run_step(step);
  }

This means steps can't ever be run in parallel. Instead, split it into two workers. The "Build" worker starts things off, and basically does:

  update_build();

(We could theoretically do this in the original process because it should never take very long, but since there's a lock and it's a little bit complex it seemed cleaner to separate it.)

The "Target" worker runs an individual target (like a command, or an HTTP request, or whatever), then updates the build:

  run_one_step(step);
  update_build();

The new `update_build()` mechanism in `HarbormasterBuildEngine` does this, roughly:

  figure_out_overall_status_of_all_steps();
  if (build is done) { done(); }
  if (build is fail) { fail(); }
  foreach (step that is ready to run) {
    queue_target_worker_for_step(step);
  }

So, overall:

  - The part of the code that updates Builds is completely separated from the part of the code that updates Targets.
  - Targets can run in parallel.

Test Plan:
  - Ran a bunch of builds via `bin/harbormaster build`.
  - Ran a bunch of builds via web UI.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1049

Differential Revision: https://secure.phabricator.com/D7890
Replace "Cancel Build" with "Stop", "Resume" and "Restart"

Summary:
Ref T1049. Currently you can cancel a build, but now that we're tracking a lot more state we can stop, resume, and restart builds.

When the user issues a command against a build, I'm writing it into an auxiliary queue (`HarbormasterBuildCommand`) and then reading them out in the worker. This is mostly to avoid race messes where we try to `save()` the object in multiple places: basically, the BuildEngine is the //only// thing that writes to Build objects, and it holds a lock while it does it.

Test Plan:
  - Created a plan which runs "sleep 2" a bunch of times in a row.
  - Stopped, resumed, and restarted it.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran, chad

Maniphest Tasks: T1049

Differential Revision: https://secure.phabricator.com/D7892
Make HarbormasterBuild a better source of truth about restarting/resuming/stopping

Summary: Ref T1049. The logic in the BuildEngine is a little different from the logic on the Build itself. Make these more consistent, and make queued commands more private.

Test Plan: Restarted, stopped, and resumed a build.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1049

Differential Revision: https://secure.phabricator.com/D7897
Improve restart/stop/resume UI

Summary:
Ref T1049. Improves the UI:

  - Pending commands, like "stopping", are shown separately from the current status.
  - Pending commands are shown on the list view.
  - Builds can be restarted, stopped and resumed from the list view.
  - Add a missing crumb.

Test Plan:
{F99022}

{F99023}

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1049

Differential Revision: https://secure.phabricator.com/D7898
Allow entire buildables to restart/stop/resume

Summary: Ref T1049. Creates convenience actions at the Buildable level to stop, resume, or restart all builds.

Test Plan:

  - Stopped all builds.
  - Resumed all builds.
  - Restarted all builds.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1049

Differential Revision: https://secure.phabricator.com/D7899
Audit - tweak colors

Summary: See github issue 413. This diff adds color to the commit view as the user expects *AND* adds green to both audit and commit views. I looked in the history (D6184) and I can't tell how expected green was, but it feels nice to me given differential color coding.

Test Plan: looked at lists of audits and commits with pretty colors.

Reviewers: epriestley, chad

Reviewed By: epriestley

CC: Korvin, epriestley, aran

Differential Revision: https://secure.phabricator.com/D7900