* Drop the in-memory database
Fixes#607
This PR drops the implementation of in-memory database traits.
They are useful for testing purposes since the tests should test our codebase
and assume the database works as expected (although a follow-up PR should write
a sanity test suite for all database trait implementors).
As complexity is worth with database requirements to simplify complexity and
add more robustness, for instance, with the following plans to add support for
transactions or buffered writes, it would become more complex and
time-consuming to support a correct database trait. This PR drops the
implementation and replaces it with a SQLite memory instance
* Remove OnceCell<Mint>
Without this change, a single Mint is shared for all tests, and the first tests
to run and shutdown makes the other databases (not-reachable, as dropping the
tokio engine would also drop the database instance).
There is no real reason, other than perhaps performance. The mint should
perhaps run in their own tokio engine and share channels as API interfaces, or
a new instance should be created in each tests
* Fixed bug with foreign keys
[1] https://gist.github.com/crodas/bad00997c63bd5ac58db3c5bd90747ed
* Show more debug on failure
* Remove old code
* Remove old references to WalletMemoryDatabase
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
The attribute `schema(as = String)` does not result in the expected
behaviour.
It does not convert Id to being represented as a simple string, but
rather simply rename the type `Id` to `String`.
This commit removes the attribute that implements utoipa::ToSchema trait
for type `Id` and adds attribute to all the types that have a keyset id
as inner type to represent it as string.
* refactor: consolidate validation checks
* refactor: melt verification checks
* refactor: mint verification
* chore: clippy
* chore: use error codes
* fix: order of verifications
* fix: p2pk test ws updates
We only expect the proof to be set to pending once. As a proof without
a signature failes before the spent check where the state is chaged.
* fix: mint_melt regtest frome wait
