ovsqlite: Add direct reader mode for nnrpd with WAL

[kev009]

This is the next step after #336, and brings ovsqlite similar to how bdb worked. The WAL PR without this change is a modest benefit so that PR still makes sense standalone but the commit is included here so this is self contained.

When WAL mode is enabled, nnrpd processes now open the overview database
directly with SQLITE_OPEN_READONLY instead of routing reads through
ovsqlite-server.  This eliminates the IPC round-trip and the
single-threaded server bottleneck for read operations, allowing read
performance to scale with the number of concurrent readers.

Direct reader mode activates automatically when walmode is true in
ovsqlite.conf AND the database is actually in WAL mode (verified via
pragma journal_mode).  Without WAL, behavior is unchanged -- readers
connect to ovsqlite-server as before to avoid EXCLUSIVE lock contention.

Key changes:
- ovsqlite.c: direct_open() opens the database read-only with schema
  version validation, journal mode verification, decompression support,
  and goto-based cleanup.  Read functions (groupstats, getartinfo,
  search) branch on direct_reader flag.  Write operations return errors
  in direct reader mode.  Falls back to server path gracefully.
- ovsqlite-server.c: WAL checkpoint at shutdown uses PASSIVE first
  (non-blocking, safe with readers connected) then TRUNCATE only if no
  readers hold pins.  Prevents server shutdown from hanging.
- ovsqlite.c: Fix pre-existing buffer leak in ovsqlite_close():
  request and response buffers from server_connect() were never freed.
- sql-read.sql: read-only prepared statements with busy_timeout=10000
  and query_only=1.
- New readercachesize config parameter (default 8 MB per reader).

Includes unit tests (WAL gating, write rejection) and integration tests
that start a real ovsqlite-server, write compressed data through it,
kill the server, and verify the direct reader can read it back correctly
including a server restart cycle.

[blgl]

Potential memory leak: you should call sqlite3_close_v2 when
sqlite3_open_v2 fails. sqlite3_open_v2 creates a connection object
even on failure (except when out of memory) to have somewhere
to store a specific error message.
This doesn't matter in ovsqlite-server since it dies if it can't open
the database, but your new client-side code keeps running.

[blgl]

I see a real risk of checkpoint starvation here. It might be necessary to add server code to checkpoint and truncate when the WAL size reaches some threshold, accepting that this will block readers for a while.

[Julien-Elie]

Thanks for your review, Bo; it is greatly appreciated.

Kevin, it is quite a great improvement. Many thanks for the extensive patch, including documentation and a test suite!

I note extra indentation in lines 728-761 of ovsqlite.c starting with start_request(request_get_groupinfo);. Just telling you to be sure a block condition is not missing in the commit. I'll reformat it when committing if that's OK for you. Unless you plan on providing an updated patch taking into account Bo's suggestions?

[kev009]

Let me work through the reviews, I'll post follow up commits that can be squashed into one when it is ready for merging.

[kev009]

@blgl I think checkpoints are addressed now but this is certainly tricky machinery. My understanding is the readers effectively never block with WAL, and use very short auto transactions, and this followup attempts to add bounded waits to the server and make forward progress.