added robustness against failing executor

When the threadpool executor failed to execute a update task, because its status had already been set to IN_PROGRESS, that update task would be hanging around forever. To address that issue, we:
- added an unclaim(...) method in the catch clause of the executor.execute block;
- added startTime and endTime fields to updateWorkerTasks so that we're able to detect zombie threads easier;
- added a workerThreadName field to updateWorkerTasks in order to have better debugging information in case of problems;
- decoupled the claim logic in two stages: first we would call claimForDispatch(...) to set the serverUUID and update the status to IN_PROGRESS (in the hope that the executor's execute will work), and when the worker's run() method is executing, we would call claimForExecution which sets the actual start time of the worker's execution; the end time is set when we set the status of the update worker task to either DONE or FAILED
fixed new metadata persistence when rescheduling

for failed tasks, copy the start- and endTime fields and workerThreadName fields from the original update task and reset it for the (new) one that's reschedules the update
Merge branch 'hotfix/better-claim'