Merge branch 'master' into v0.9.0031-deploy-140404b
added try...catch block around updateTimeBounds

This could be zombie-threads culprit! If an exception is thrown here (and we now it happens quite often) then we never return an updateResult and that's something we absolutely need in order to properly handle the UpdateWorkerTask record (so it's either being archived or rescheduled)
try..catch on updateTimeBounds@historyUpdate

forgot to add the try..catch block on the historyUpdate's updateTimeBounds call
display live serverUUIDs in the main admin page

(Useful for debugging zombie threads)
set endTime for failed updates
reset the serverUUID to unclaimed only if scheduled

That we we keep a track of serverUUID for recently completed tasks
fixed log traces
removed unnecessary called to persist() on managed entities
added more debugging info
avoid potential entity clashes

Here we try to limit potential RAM/database entity inconsistencies due to retrieving UpdateWorkerTask entities to the session twice in one unit-of-work
update local task instance with db retrieved one
delegate persistence of dispatched tasks

Nested (/intermediary) persistence inside a @Transactional method isn't supported by spring, which forces us to create a separate service to ensure that the correct task data is persisted to the database before spawning the worker threads which rely on it.
Merge branch 'hotfix/zombie-threads-fix'