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.

• Ran a bunch of builds via bin/harbormaster build.
• Ran a bunch of builds via web UI.