[#1025] Stop a restore which cannot lock its backend instead of completing it

[vharseko]

Fixes #1025.

Rebased onto master after #969 (e86f702f8e) landed; the branch is the single commit 3e600a73a1, its content unchanged from the original ad67ade1e9 (same patch-id).

The bug

RestoreTask.runTask() guarded the restore with if (verifyOnly || lockBackend(backend)) and had no else. When the backend lock was refused - another process holds it, or the lock file cannot be created - the whole restore block was skipped, errorsEncountered stayed false, the finally re-enabled the backend and told the listeners the restore succeeded, and the task returned getFinalTaskState(), i.e. COMPLETED_SUCCESSFULLY. The restore CLI printed the ERR_RESTOREDB_CANNOT_LOCK_BACKEND line from the task log and exited 0 right after it.

The change

A refused lock ends the task the way BackupTask and ImportTask already end theirs, and the way #969 already ends a failed disableBackend():

if (!verifyOnly && !lockBackend(backend))
{
  errorsEncountered = true;
  return TaskState.STOPPED_BY_ERROR;
}

The return passes through the finally, which re-enables the backend and notifies processRestoreEnd(..., false). The rest of the RestoreTask hunk is the de-indentation of the former if body - ?w=1 shows the five real lines.

restore --verifyOnly is unaffected: it never takes the lock.

Test

TestBackupAndRestore.testRestoreEndsInErrorWhenTheBackendCannotBeLocked - self-contained: it backs userRoot up into a temporary directory, takes a shared lock on the backend's lock file and restores from that backup. LockFileManager reference-counts shared locks, so the task's disableBackend() releases the backend's own reference but not the test's, and the exclusive lock the restore needs is refused with ERR_FILELOCKER_LOCK_EXCLUSIVE_REJECTED_BY_SHARED. Asserted: STOPPED_BY_ERROR, one begin and one end notification, successful == false at the end notification, and userRoot registered again afterwards.

Before the change the test fails with expected [STOPPED_BY_ERROR] but found [COMPLETED_SUCCESSFULLY], the task log carrying the refused-lock error. It also runs the restore half of #969's finally - the backendDisabled re-enable and the !errorsEncountered notification - which the review of #969 noted no test executed.

Run: TestBackupAndRestore 13/13, TestImportAndExport 14/14, PrivilegeTestCase 185/185, ReSyncTest 2/2, LDIFBackendTestCase 22/22.

[vharseko]

@maximthomas rebased onto master now that #969 has landed - the merge conflict is gone. The branch is the single commit 3e600a73a1, the same patch as ad67ade1e9 (identical patch-id), so there is nothing new to review beyond that one commit. The description no longer mentions the stack.