When provisioning calls the payload copying workqueue
for a throttled copy, it can time out, and then abort
its request.  If the copy is actually running (as opposed
to merely queued and waiting to run), the abort includes
calling this code in tasks.ProcessPoolTaskManager:
  def TerminateTask(self, request_id):
    del self._pending_results[request_id]


... that is, the method merely removes the record of the
running task without actually stopping it.  This change
means that subsequent queries to `HasCapacity()` will
return true, allowing `ProcessRequests()` to add additional
tasks.

We're using `multiprocessing.Pool` to keep track of the work,
so the extra tasks would queue up inside the Pool object,
taking up time, but not bandwidth.  The net effect is that some
copy tasks would show excessively long run times, rather than
long wait times.  This could also aggravate wait times, and
cause more client timeouts through this sequence:
  * Request A times out while running, and the client requests
    abort.
  * This bug allows a new request B to be started before A
    terminates.  The request will be accounted for as running,
    even though it gets no processing time.
  * If request B times out, the task for B _will_still_run_.
    It may not even start processing until after being aborted.
One effect of clients aborting work should be that when wait
times are long, the system self-regulates by eliminating work.
But, in the scenario above, work that should have been stopped
instead plows forward in stealth mode without reducing system
load.