Add initial GitHub Actions runner support

[bduffany]

When enabled (behind flag), allows using BuildBuddy to run GitHub actions in a warm microvm. Users can install the BuildBuddy GitHub app, then change their GitHub workflow YAML to specify runs-on: buildbuddy. BuildBuddy will then spawn an ephemeral runner (as an RBE action) for each workflow_job.queued event, executing the runner within a warm microVM.

The ephemeral runner uses a "just-in-time config" which acts as a one-time-use token that allows the runner to execute a single job. Once the runner is done executing the job, it unregisters itself from the repo (i.e. it will no longer be usable for executing more jobs and won't show up in Settings > Actions > Runners). The config is scoped to a single repo but is not scoped to a particular job ID. So the scheduling model is less like "1 job ID => 1 runner ID" and more like "N jobs => N runners".

Limitations:

• We don't yet actively monitor workflow job progress, so if a runner crashes or fails for some reason then there may be jobs stuck in "queued" state. If this becomes a major issue while testing in dev, we can explicitly track workflow jobs and runner executions, and start extra runner executions if the number of jobs exceeds the number of runner executions. See Option to limit runner to a particular run or job actions/runner#620 (comment) for more background.
• We may occasionally spawn too many runners, e.g. if the user cancels a workflow job before it is accepted by a runner. This case is mitigated by applying an "idle timeout" to each runner. We execute the runner alongside a "monitor" process, which kills the runner after 5 minutes if it hasn't printed "Running job:" to its logs yet.
• The runner image is based on our rbe-ubuntu20-04-workflows image, not GitHub's Ubuntu 20.04 machine image, so some system tools may be missing. This means that runs-on: buildbuddy does not yet "just work".
• The runner image is pretty huge (3GB) and we don't warm it up yet during executor startup. We could either add the actions runner setup into our current workflows image (since we already warm up the workflows image), or find some way of speeding up image conversion, e.g. https://github.com/buildbuddy-io/buildbuddy-internal/issues/3137
• Making use of a warm bazel workspace requires a bunch of manual setup in the action. In future PRs, we can provide a GitHub action like "buildbuddy-io/bazel-ci-setup" to make it easier. I did some testing in a separate private repo to make sure that it is feasible (and that we can reuse a bazel server instance etc.) - it took a while to sort out the issues but the results are looking good so far (I tested with buildbuddy-io/buildbuddy and got some runs that take only a few seconds, with the git repository and bazel server persisting between runs)
• We don't yet set GIT_BRANCH env vars etc. in order to get the same quality of task => snapshot matching and executor routing that we have for BuildBuddy workflows. We can add this in later if the workflow_job event contains the necessary info, but for now I think we can live with actions being assigned to suboptimal snapshots just for GitHub Actions.

Related issues: N/A

[tylerwilliams]

I would be more explicit about calling these githubWorkflow events.

For better or worse workflow jobs already means something to us all, so it's kind of confusing to change the meaning of that name now.

[bduffany]

Renamed startWorkflowJob to startGitHubActionsRunnerTask.

I would like to keep this func handleWorkflowJob the same though - in handleWebhookEvent above, the function that handles *github.FooEvent is called handleFooEvent which I think is a nice convention. To make this more obvious, the latest commit also gets rid of handleBuildBuddyWorkflowEvent which was being used as a catch-all for the remaining event types, which seemed sort of unclear. Replaced that with explicit handlers for Push, PullRequest, and PullRequestReview events, and those handlers call maybeTriggerBuildBuddyWorkflow now