refactor!: store inscription data in postgres instead of sqlite

[rafaelcr]

This PR is a very extensive refactor that migrates the underlying inscription data storage engine from a local SQLite database to a PostgreSQL database. This is a breaking change that requires a full reindex of the entire Bitcoin inscription history. Some of the most significant changes are:

chainhook-postgres

A new component called chainhook-postgres is created which contains tools for working with pg databases such as:

• Automatic connection pool management and reuse
• Support for large integer number encoding (u64, u128) into PG numeric columns
• Easy to use closures for automatic transaction commits/rollbacks (with_pg_transaction)
• Easy to use methods for connecting to a DB with optional retry

This is meant to be a shared component which will be moved to the chainhook repo in the future once all indexers are moved to postgres.

DB schema upgrades

This refactor creates a full DB schema that stores all inscription data, including cache tables for counts, ownership pointers, etc. Previously, SQLite only stored a partial data set that needed to be complemented with a bitcoind RPC call in order to serve the inscription data to predicates. This will no longer be necessary.

More importantly, since we now have a full DB schema the Ordinals API will now be able to read directly from this DB without a re-ingestion in order to serve its endpoints. This also applies to the BRC-20 index.

To configure the new database connections, these (example) entries will need to be added to the .toml config file:

[ordinals_db]
database = "ordinals"
host = "localhost"
port = 5432
username = "postgres"
password = "postgres"
search_path = "public"

[brc20_db]
database = "brc20"
host = "localhost"
port = 5432
username = "postgres"
password = "postgres"
search_path = "public"

This also renders the ordhook-sdk-js component obsolete.

Forced linear indexing

Starting with this update, ordhook will only be able to index in sequence, without skipping blocks, and starting at the current chain tip. This means that per-block scanning, per-transaction scanning, etc. is now disabled.

This change was done to simplify the codebase, to make a global index state easier to manage, and to make DevOps tasks more predictable.

Update to Rust 1.80.1

Ordhook is now upgraded to Rust 1.80.1.

CI upgrades

Since we now use Postgres, the CI was upgraded to include an integration environment with Docker+Postgres.

Closes #374

[zone117x]

This looks spooky, I'll just assume it's all good

[rafaelcr]

Oh, good catch, I remember doing that to get over some compiler thing. I'll take another look to see if there's a better way to handle the Transaction lifetime

[zone117x]

There's a few pieces of code implemented here that I'm a bit surprised isn't available/usable from existing postgres related crates (e.g. u64<->numeric handling).

But from a quick review, this looks great!