Gracefully handle database corruption

[calmh]

Sometimes syncthing crashes with "foo: leveldb/table: corruption on data-block ..." which just means data on disk is not what was expected and the database is essentially toast. Today, we just keep crashing in a loop until the user discovers this and files an issue or drops the database.

We could, instead, move the database aside and start from scratch. Assuming we run with the monitor. Which maybe we should always do.

[neekt]

I came here specifically to see if this issue existed.

Syncthing really shouldn't just crash silently in the background because of a corrupt database. There are two problems I can see with it doing this:

1. Potential for data loss - it can leave the user unaware that their files are no longer being synced, potentially for days. This runs the risk of data loss, e.g., when all files are being synced to a machine where incremental backups are made (e.g., from a phone to a PC or server).

2. It's not user friendly - there is no clear explanation for why it keeps crashing without digging into log files (full of technobabble and, in my case on Linux, in a hidden .config directory), what it signifies (potentially hardware failure or a corrupt file system), or what can be done about it without digging into GitHub issues (generally too technical for your average user).

I propose that, at the very least, Syncthing should clearly notify the user that it is unable to sync files because of a corrupt database, so that the user is immediately aware of the issue.

Ideally, it might also offer to reset the database so it can resume syncing files, including a warning about any potential consequences of doing this, and a warning about what a corrupt database might mean.