Don't restore files that still exist unchanged

[grote]

Before, we would restore files no matter what. The idea was that restore only happens in SUW, so there would be no pre-existing files anyway. In practice, we created duplicated with (1) suffixes which is not really desirable.

To support #671, we now check if the file is already there (and if its size and lastModified timestamp is still the same) and if so, we don't restore it. This is a quick implementation and could be better in the sense that we could show the user how many existing files were retained instead of just claiming restore.

This MR also includes some other commits fixing some issues I encountered along the way. So best to review individual commits.

[t-m-w]

The title says this won't restore "files that still exist unchanged", but the description says it won't restore files that already exist at all. Which behavior should I expect?

If the latter: I know this is a quick implementation, but in the future, it would be useful to either allow some kind of choice or to still restore files that differ, even if with a (1), especially if the user is intentionally trying to recover changed files (e.g. ransomware, if that were more of a thing on Android).

[grote]

The title says this won't restore "files that still exist unchanged", but the description says it won't restore files that already exist at all. Which behavior should I expect?

I clarified the description. If the file has changed, we still do the (1) restore.

If the latter: I know this is a quick implementation

Indeed, this is just to fix the biggest annoyance where most of your files would get duplicated if you restored again.

it would be useful to either allow some kind of choice or to still restore files that differ, even if with a (1), especially if the user is intentionally trying to recover changed files (e.g. ransomware, if that were more of a thing on Android).

I think we should always restore files that differ, so maybe no choice needed here?
If the user is only after certain files, they can now use the new file restore chooser.

[t-m-w]

This looks like it's working! One observation, not a problem really: if you have a different variant of a file locally, then the one from the backup is restored with a (1) or (2), etc on the end, as expected. If you restore the same files backup again, although you already have the restored file as (1), it will restore again as a duplicate of (1) as (2). Again, just thought I'd mention for completeness, but not really unexpected behavior.

Tested deleting a file, and it came back. Tested changing a file, and it was restored with a number on the end. Tested creating a new file, and it was not removed.

[grote]

Thanks for testing!