Fixes to the backup import

[iequidoo]

See commit messages.

No tests, i only checked this manually with deltachat-repl.

[flub]

High level looks fine. I didn't review the code detailed though, if you'd like me to I can on Monday when I have a full-size computer for it

[iequidoo]

I checked with deltachat-repl, this removes the unpacked files if the import fails, and if the reason of failure is fixed afterwards, the next import run finishes successfully.

[link2xt]

From the first commit message:

If a db wasn't imported successfully, unpacked blobs aren't deleted because we don't know at which step the import failed and whether the db will reference the blobs after a restart.

Why do we care about existing blobs? Backup is always imported into unconfigured account that we don't care about, it is fine to completely remove its blobs and database.

It should be safe to import backup like this:

1. Remove database.
2. Remove all blobs from blobdir.
3. Unpack the .tar contents into blobdir.
4. Move the new database over.

If any step after removing the database fails, we will have no database and create a new one next time.

To simplify further, there is no need to even remove existing blobs, if they exist they are non-sensitive generic images like device chat avatar, it will be garbage-collected anyway.

It seems the only change needed for the fix is to move the code that calls fs::rename (or sql.import) on the unpacked database to the end of the unpack loop. Trying to remove created garbage on failure is also somewhat helpful but cannot be done reliably anyway as the app may be killed anytime in progress: in the end account manager should care to delete the account folder before removing it from accounts.toml.

[iequidoo]

Why do we care about existing blobs? Backup is always imported into unconfigured account that we don't care about, it is fine to completely remove its blobs and database.

If the account manager isn't used, e.g. in deltachat-repl, while we import a backup into an unconfigured account as well, we mustn't remove already unpacked blobs if the db itself has been potentially imported, otherwise it may reference removed blobs. The user may forget to check the import result and try to use the inconsistent account. Maybe this is indeed unimportant and we can always remove blobs in fail scenario.

The first commit is about fixing #4307 in most cases so that if there's insufficient disk space we do the cleanup asap on failure, not on the next program run or so. Though it's still good to clean up half-imported accounts after restart f.e. Also this commit makes things happen in a well-defined order: first unpack everything, then import the db.

[link2xt]

If the account manager isn't used, e.g. in deltachat-repl, while we import a backup into an unconfigured account as well, we mustn't remove already unpacked blobs if the db itself has been potentially imported, otherwise it may reference removed blobs.

In my last message I propose to only move unpacked database over as the last step. Worst case this step fails and user is left without the database at all and blobdir full of files that we can try to remove but that will be garbage-collected anyway at the next housekeeping with a new empty database.

[iequidoo]

In my last message I propose to only move unpacked database over as the last step. Worst case this step fails and user is left without the database at all and blobdir full of files that we can try to remove but that will be garbage-collected anyway at the next housekeeping with a new empty database.

But this is exactly what is done in the first commit. I only added blobs removal also so that if we fail because of insufficient disk space, we don't worsen this situation. I only don't remove blobs after a try to import the db. Even if the db is imported with simple rename(), we can get a temporary IO error and the operation may succeed finally, so it's not safe to remove blobs. But this matters only for deltachat-repl which doesn't use the account manager, so it's not very important