feat: implement multiple read single write for sqlite

[hansieodendaal]

Description

• Implemented a generic system-wide pool connection manager for diesel SQLite connections that uses the modern Write-ahead Log (WAL) SQLite3 database mode to speed up database operations (see https://www.sqlite.org/wal.html) with a configurable pool size.
• Changed the Wallet's SQLite database connection to make use of the pool connection manager.
• Refined SQLite profiling trace logs to only log an entry if the total time is > 1ms - this cut down on noisy entries as most database calls are now < 1ms.
• Notable SQLite pragma settings:
  • PRAGMA schema.journal_mode = WAL
  • PRAGMA schema.locking_mode = NORMAL
  • PRAGMA schema.synchronous = | 2 | FULL
  • PRAGMA wal_autocheckpoint = 1000 (the default)

Motivation and Context

The wallet's database connection was not optimal.

How Has This Been Tested?

• Unit tests
• Cucumber tests (npm test -- --tags "not @long-running and not @broken")
• System-level tests with positive results all around (see discussion):
  • Configuration: Base node + console wallet + merge mining proxy + XMRig -> Mining
  • Test 1: Moderate coin split (22 transactions producing 3124 outputs)
  • Test 2: Moderate stress test (2x simultaneous make-it-rain transactions from one sender to two receiving wallets of 250 transactions each)

The graphs below show the SQLite WAL mode profiling for the above two tests (sender wallet only) with a pool size of 16 for all read and write database operations where the total time (acquire lock time + db operation time) was larger than 1ms. The wallet in question had a communications breakdown to its connected base node for a while after all transactions were completed and when it eventually gained an RPC connection validation protocols for all 500 transactions queried the base node as fast as possible, which panned out in some of those protocols waiting for a pooled connection. The actual time db operations will wait for a write operation to conclude is managed by SQLite and bunched within the db op time measurement.

[philipr-za]

Very nice, looks good to me.

[philipr-za]

Nit: this is fine, just a note that you could explicitly drop() the pool rather than using a {} scope which I think is a bit more explicit and easy to use.