Instead, use `INSERT` and `ON CONFLICT`. The reason is that in case of
conflicts, the `REPLACE` will trigger a DELETE and then perform an INSERT, as
outlined in the documentation[1], and that may cause a cascade of deletion due
to our FOREIGN KEYs.
Here is the official documentation:
```
When a UNIQUE or PRIMARY KEY constraint violation occurs, the REPLACE algorithm
deletes pre-existing rows that are causing the constraint violation prior to
inserting or updating the current row and the command continues executing
normally. If a NOT NULL constraint violation occurs, the REPLACE conflict
resolution replaces the NULL value with the default value for that column, or
if the column has no default value, then the ABORT algorithm is used. If
a CHECK constraint or foreign key constraint violation occurs, the REPLACE
conflict resolution algorithm works like ABORT. When the REPLACE conflict
resolution strategy deletes rows in order to satisfy a constraint, delete
triggers fire if and only if recursive triggers are enabled. The update
hook is not invoked for rows that are deleted by the REPLACE conflict
resolution strategy. Nor does REPLACE increment the change counter. The
exceptional behaviors defined in this paragraph might change in a future
release.
```
[1] https://www.sqlite.org/lang_conflict.html
This is a minor improvement over the SQLite crate, which performs fewer SQL
statements and fetches multiple results instead.
This will also remove some redundant commit() and rollback calls. Rollback
already happens on drop, and there is no need for a commit if the database
hasn't changed, as the transaction is used as a locking mechanism in this
context.
fix(mint/sqlite): add pending proof state
fix(mint): adding proof to pending before checking current
fix(mint): remove double call to verify melt quote
