Mint, wallet: move migration into into new(), create backup before migration

[ok300]

Description

This PR removes the need to call migrate() when initializing a wallet or a mint.

---

Notes to the reviewers

• Add the ability to create timestamped backups according to a configurable backups_to_keep value
• Backups are performed on initialization, before migration
• Redb new() methods were simplified by extracting migration code to migrate()
• DB error types were added to cover DB initialization and backup issues
• SQLite wallet and mint error types were consolidated in cdk-sqlite/src/error.rs

---

Suggested CHANGELOG Updates

CHANGED

• Simplify mint and wallet initialization: remove need to call migrate()
• Automatic DB backup on startup with configurable backups_to_keep

ADDED

REMOVED

FIXED

---

Checklist

• I followed the code style guidelines
• I ran just final-check before committing

[thesimplekid]

I've actually thought about going the other way with this and changing the redb to be in line with the sql one and force migrate to be called explicitly. My reasoning for this is it gives the user better control over db changes and allows them to create a backup before calling migrate. The other way we could handle this is create a backup before the migration, but do think we want to encourage or force a db backup before a migration.

related: #400

[ok300]

we want to encourage or force a db backup before a migration

Agree.

If we give control to the caller over when to call migrate, then we must also give them control over backup / restore. Trickier IMO is when they have to make sure to call backup then migrate in the right order and at the right place after an upgrade. Forgetting to call migrate after an upgrade could lead to weird problems.

A simpler and more robust way is IMO to encapsulate this in the DB initialization:

• create a backup on every startup (up to e.g. 10 backups)
• call migrate

Then we can offer the methods

• list_backups, which would list the available backups (incl. the timestamp and CDK version used for each)
• restore, which the caller could offer in an Advanced view in their app if they wish

What do you think?

[thesimplekid]

Yes, you're right we should do it in the the DB initialization and create backups then. For the wallet especially I don't think we should create a backup each time as it uses more storage then is really needed but we can check if a migration is needed and back up then. For the mint a configurable number of backups should be fine.

[ok300]

The PR is ready for review.

As I found no way to tell in advance (e.g. before migrate()) whether the DB schema is changed or not, the PR now simply creates a new backup each time on new(). The number of backups is controlled via backups_to_keep.