TideSQL 4 PATCH (v4.6.1)

[guycipher]

stop shared-locking plain reads, only write-intent takes a row lock

Under pessimistic_locking a plain SELECT under REPEATABLE READ or SERIALIZABLE
took a per-row shared lock through the plugin's lock manager. The library
already enforces those levels from its MVCC snapshot -- it tracks the read set
and aborts a conflicting transaction at commit, which the plugin surfaces as
HA_ERR_LOCK_DEADLOCK for MariaDB to retry -- so the shared read lock duplicated
that guarantee while charging a heap allocation and a partition mutex on every
row a scan walked past.

tdb_lock_mode_for_read now returns a lock only for write-intent statements,
which take X. UPDATE, DELETE, SELECT FOR UPDATE and SELECT IN SHARE MODE still
lock the rows they touch; plain reads never lock at any isolation level,
matching InnoDB's non-locking reads. The pessimistic_locking sysvar text and the
read-path comments are updated to describe the new behaviour.

Rewrote tidesdb_pessimistic_shared and tidesdb_pessimistic_upgrade to the new
semantics, since the shared-lock and S-to-X-upgrade cases they asserted no
longer exist. shared now proves two plain reads run concurrently and a plain
read does not block a writer while SELECT ... FOR UPDATE still does; upgrade now
proves a read-then-write transaction takes X at the write with no upgrade and no
self-deadlock