For reference of a specific example of this problem, see b/72967028.

Here's the sequence:
  * A DUT had a hardware problem such that it routinely failed Provisioning.
  * The DUT was locked, and a replacement ordered.
  * When the replacement arrived, the need was to run the `deploy` tool to
    make sure that the DUT+servo were working well together.  That turned
    up a comedy of errors.

These are all of the bad things that prevented the deploy tool from just
working:
  * The DUT, once on the shelf, was in working order.
  * The DUT, when locked, was in Provisioning state.  The DUT was
    unable to transition out of Provisioning state while locked.
  * Once unlocked, the failed Provision task finally registered, and
    the scheduler tried to repair the DUT.
  * The deploy command requires the DUT to be locked (or lockable) and in
    the Ready or Repair Failed state.
  * But... It seems that locking a DUT when it's in some other state no
    longer allows transitioning back to idle.

It used to be that locking a DUT that was in use just meant that new work
couldn't be scheduled.  Existing work would finish, and the DUT would
transition back to Ready or Repair Failed.  Because that no longer happens,
the `deploy` command had trouble working in this case.

I don't know quite what the fix is, but in theory, the thing we need is
for the scheduler to go back to allowing DUTs to transition to an idle
state when locked.