Support Postgres as a persistence backend

[etorreborre]

This PR adds the possibility to use Postgres as a backend to persist data for an Ockam node.

In order to use a Postgres database simply set the following environment variables:

• OCKAM_POSTGRES_HOST: for example localhost
• OCKAM_POSTGRES_PORT: for example 5432
• OCKAM_POSTGRES_DATABASE_NAME (optional): for example postgres
• OCKAM_POSTGRES_USER (optional): for example admin
• OCKAM_POSTGRES_PASSWORD (optional): for example password

Implementation notes

This PR touches a large number of files and the following sections will help the reviewer understanding the changes.

Driver

The sqlx library provides an Any driver, which replaces the SQLite driver used before this PR.
With the Any driver and its associated types, AnyConnection, AnyPool, Type<Any> etc... we can open a connection to either a SQLite or a Postgres database by specifying the proper URL:

• sqlite:file:in-memory?mode=memory&cache=shared for an in-memory SQLite database
• sqlite:file://my-file?mode=rwc for an on-disk SQLite database
• postgres://admin:password@localhost:5432/postgres for a Postgres database

This logic is encapsulated in a new DatabaseConfiguration type.

The result of this driver change is that a number of method signatures had to be changed from ... SQLite ... to ... Any ....

Queries

Some queries had to be changed in order to work with both databases.

In particular the queries of the form INSERT OR REPLACE don't work with Postgres. Those queries have been replaced with INSERT ... ON CONFLICT ... DO UPDATE | NOTHING.

Data types serialization

The mapping of Rust types to database types is quite different between SQLite and Postgres.
To support this properly:

The ToSqlxType typeclass has been removed in favor of using the Encode and Type typeclasses from sqlx directly. While this typeclass was useful when using SQLite only, it became a source of encoding bugs with both Postgres and SQLite.

Reading boolean and optional values from the database was not working out of the box. This was fixed via:

• A Boolean datatype to read a boolean value from a database column
• A Nullable<T> datatype to read an optional value from a database column possibly containing NULL values
• Two PRs to the sqlx library:
  • feat: support the Postgres Bool type for the Any driver launchbadge/sqlx#3291 (merged) to support the Bool type.
  • Track null arguments in order to provide the appropriate type when converting them. launchbadge/sqlx#3298 (not yet merged) to track null values types.
  • This explains why the sqlx dependencies mentioned in the Cargo files now point to a fork.

Tests

Repositories

All the repositories code is now tested with 3 databases: SQLite in-memory, SQLite on-disk and Postgres (if available in the environment). This test support is provided by the sqlx_database::with_dbs function.

Execution

Note that you need to run the tests sequentially if you run them with a local Postgres database since it will be shared between all tests. For example:

cargo --locked nextest --config-file ./tools/nextest/.config/nextest.toml run --no-fail-fast --test-threads 1

Clean-up

For the same reason, some system tests are now calling TestNode::clean() in order to make sure that the database is cleaned-up before the test runs.

CI

I have added a CI job to run all the nextest test suite with a Postgres database. That job only selects test names containing sql, to cover all the repositories, and cli_state to test the high-level behavior which generally involves some persistence.

Vaults

The modeling for vaults has changed slightly. An enum has been introduced to represent exactly a vault metadata:

pub enum VaultType {
    DatabaseVault {
        use_aws_kms: UseAwsKms,
    },
    LocalFileVault {
        path: PathBuf,
        use_aws_kms: UseAwsKms,
    },
}

A vault is either stored directly in the database, with some dedicated tables, or in a file (using SQLite).
The naming of is_kms has been changed to use_aws_kms to indicate that:

• If the Vault uses a KMS it is specifically an AWS one
• Not all of the Vault data is stored in the KMS. Some data is still stored locally, only the signing keys are stored in the KMS.
• I have also made some change to the output of ockam vault list/show to better reflect the vault types:

❯ ockam vault list
   │ Name: default
   │ Type: Internal

   │ Name: v1
   │ Type: External
   │ Path: /Users/etorreborre/.ockam-4/vault-v1

   │ Name: v2
   │ Type: External
   │ Path: /Users/etorreborre/.ockam-4/second-vault

   │ Name: v3
   │ Type: External
   │ Path: /Users/etorreborre/.ockam-4/vault-v3
   │ Uses AWS KMS: true

• The JSON output of the ockam vault show command also changes. This is not necessarily the best JSON output but I didn't try to improve it for now.

[SanjoDeundiak]

Nice!

[adrianbenavides]

Awesome! I pray to the gods that we never have to support oracle 😄