This PR adds support for locking files if the backend supports it.
To activate locking, set the option `--file-lock-duration=30D` and the backup will lock the files.
If the database is rebuilt with the intention of continuing the backups, use the option `--repair-refresh-lock-info` which will update lock information in the database after recreating the database.
The locking works by asking the backend to lock files after a backup has completed.
The implementation keeps track of which files are currently assigned a lock and prevents attempting to delete the files that are currently locked.
Note that the bucket should not have a default lock policy as Duplicati needs to finish the backup before the locking is applied.
In this initial version, Azure Blob Storage, B2, S3 and iDrive are supported with locking.
The CLI is updated to allow setting locks on a specific version. The backend tool is updated to allow setting locks on specific files.
The default is to report progress every second.
In some cases the report output is stuck at the "Starting backup..." phase.
This PR adds a new `Starting_Operation` enum to indicate that we do not yet know which operation is starting.
Then an additional trigger is added to flush the progress when the pahse changes. This means that as soon as we know which operation is active, this will be flushed to the UI.
Added a delete page with options to delete the local database, as well as the remote files.
Added a captcha to protect against automated attacks that would attempt to delete the remote files.
This fixes#1201
Implemented better output for Restore.
Fixed a problem with errors during dispose, and a problem with selecting filesets that do not exist.
Fixed a bug with restore if a file existed with some correct data, a copy would be restored with partial data.
Added check to try to avoid excessive restores of the same files if a file in another version already exists.
Carl Johnsen