Warning: This build has drifted.
The coverage report for this pull request build may be inaccurate because its base commit is no longer the HEAD of its target branch.
This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

    • Learn more: For more information on this, see Tracking coverage changes for pull request builds.
    • Fix now: For a quick fix, rebase this PR at GitHub. Your next report should be accurate.
    • Prevent going forward: To avoid this issue with future PRs, see these Recommended CI Configurations.

readonly: test the exemption lifecycle, log the discarded error

Three fixes from review.

The exemption flag had no test driving it. TestReadOnlyTxIsExempt proved
handleErrorPacket reads it, but set the field itself, so three mutations
survived the full suite: begin setting it unconditionally, and either of
Commit or Rollback failing to clear it. The first is the worst — every
transaction exempt means any connection that has ever run a BeginTx stops
rejecting read-only errors for the rest of its life in the pool, the feature
silently off. TestReadOnlyTxLifecycle drives begin/Commit/Rollback against a
mock server and kills all three.

ResetSession now clears the flag too. Every sql.Tx ends in Commit or Rollback
so this should be unreachable, but the stuck direction is the unsafe one and
a pooled connection's assumptions belong there.

The server's error was discarded with nothing logged. For the failover this
is written for that is fine — database/sql retries and the caller sees
nothing. For a target that stays read-only it is not: the retry budget burns,
the caller gets a bare driver.ErrBadConn, and the one string that named the
problem was assembled nowhere. Log it before closing.

README: name the 1290s that are not failover (secure_file_priv,
super_read_only, innodb_read_only, --skip-grant-tables), and say plainly what
a deliberately read-only deployment should do now that the option is gone.