This is follow up to bug 722961; details of the original failure
are described there.

Recently, 4 cave DUTs went offline, and subsequently failed repair.
Repair failed because of two apparently distinct servo failures.

Nominally, our process for this failure works this way:
  * The deputy, after confirming that it's safe, balances pools to
    get the failed DUTs out of the critical pool.
  * At some point, the failed DUTs come up in the regular repair
    list for englab-sys-cros@
  * The responsible tech sees that servo failed, troubleshoots and
    fixes the servo, then uses the servo to repair the DUT.

However, we have no feedback in the process to know if it's working
as intended, or tools to help improve the process:
  * We don't have easily accessible history of the servo to determine
    when it went bad.
  * The tech's repair actions don't produce an easily accessible
    history, so we don't know what sorts of manual actions are common
    and therefore how we might improve diagnosis or check for errors
    more proactively.
  * We don't know how hard it is for techs to troubleshoot these
    problems, or what tool improvements would help them.

We gather much of the data required already.  What's needed are steps
like the following:
  * Index special task results stored in gs://chromeos-autotest-results.
  * Include machine-readable special task summaries (cf  bug 708312 ).
  * Make key work in deployment_test and repair_test go through a
    special task.
  * Create tools to use the data implied by the above changes.