Single writer/multiple reader MMR store

[m-kus]

This PR replaces the SQLite store backend from rust-accumulators with a new one, more configurable. The implementation:

• Adds a new MMRStore that implements the BlockMMRStore trait with SQLite backend
• Uses WAL mode for concurrent read access during writes
• Implements transaction support for atomic operations
• Separates reader and writer connection pools for better concurrency
• Stores block headers directly in the database instead of relying on RPC calls
• Refactors the BlockMMR to use the new storage interface
• Updates the indexer to work directly with the MMR instead of going through the app client

The PR also adds the async-trait dependency and integrates the accumulators crate from the workspace dependencies.

[m-kus]

• Add chain state indexing and RPC endpoint #383
• Thread safe MMR #379
• Expose endpoint to fetch multiple block headers #377
• Single writer/multiple reader MMR store #376 👈 (View in Graphite)
• backend: remove file sink #375
• Fix typo #382 : 2 other dependent PRs (#378 , #381 )
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[maciejka]

Does it make sense to use sqllite if it require maintaining extra logic to manage connections? Wouldn't a good old postgres be a better choice?

[m-kus]

External PG seems like an overkill, embedded db is a simpler option. We do need acid transaction though (to avoid weird indexing issues), so sqlite is a good choice.
I was actually thinking of using mdbx but it's really clumsy to use with async. So either rewrite rust-accumulators (which I'd really want to avoid) or just keep as it is, just expose a bit more control to the pool management (which is implemented).