Handle sqlite3PagerSharedLock() error SQLITE_BUSY
Handle sqlite3PagerSharedLock() error SQLITE_BUSY

In a multi-threaded non-WAL-journaled setting, concurrent writers can
block readers causing sqlite3PagerSharedLock() of verify_page1() to fail
with SQLITE_BUSY. Consequently, sqlite3PagerPagecount() returned 0 as
the page count of the database, which resulted in sqleet thinking the
database was empty and thus using a wrong KDF salt. This ultimately
caused accessing an encrypted database to fail with SQLITE_NOTADB.

This commit adds missing handling of SQLITE_BUSY when acquiring a shared
pager lock. If blocked, sqleet invokes SQLite3 busy handler configured
with sqlite3_busy_timeout() or sqlite3_busy_handler() functions. If the
busy handler is unset or it returns 0, then SQLITE_BUSY becomes return
value of sqlite3_key() (unfortunately sqlite3_open() with key embedded
in the URI does not pass SQLITE_BUSY from sqlite3_key() to the caller).

Future work includes optional skipping of the verification of the codec
encryption key (so that sqlite3_open() & sqlite3_key() succeed with an
incorrect key, but subsequent attempts to access the database fail with
the incorrect key). Moreover, shared cache feature of SQLite3 appears to
be unstable when using sqleet in a multi-threaded program. Shared cache
with sqleet-databases needs more testing to guarantee a proper support.

resilar/sqleet,resilar/sqleet