newsql_get_snapshot: fall back to stored snapshot on ha-retry

[markhannum]

Problem

On an HA retry (is_hasql_retry=1), the client replays the transaction
starting from the snapshot LSN that was established during the original
BEGIN. That LSN is stored in clnt->snapshot_file/offset by
is_snap_uid_retry at BEGIN time.

Statements after BEGIN (INSERT, SELECT, COMMIT) carry no
snapshot_info in their CDB2SqlQuery protobuf because only the BEGIN
message carries it from the client. newsql_get_snapshot was not
checking clnt->snapshot_file as a fallback, so it returned file=0
for all post-BEGIN statements on a retry path.

initialize_shadow_trans passes that file/offset into
trans_start_serializable. When file=0 and is_ha_retry=1,
the assertion at bdb_osqltrn.c:278 fires and kills the node.
Because the assertion is in common code reached by every thread, all
three nodes crash simultaneously.

Root cause

newsql_get_snapshot (plugins/newsql/newsql.c) only copied
snapshot_info from the current sqlquery. It had no fallback for
the retry case, unlike fill_snapinfo which already handled this by
checking clnt->snapshot_file when is_hasql_retry is set.

Fix

Add the same fallback to newsql_get_snapshot: when *file is still 0
after checking sqlquery->snapshot_info, and clnt->is_hasql_retry is
set, use clnt->snapshot_file/offset instead. This mirrors the
existing logic in fill_snapinfo and makes the two paths consistent.

Testing

Reproduced with a 3-node cluster under election / network-partition
stress (jepsen-style nemesis testing). The assert(file) crash at
bdb_osqltrn.c:278 no longer fires after this change.

Files changed

• plugins/newsql/newsql.c — 7-line addition in newsql_get_snapshot

[roborivers]

Cbuild submission: Success ✓.
Regression testing: Success ✓.

The first 10 failing tests are:
consumer_non_atomic_default_consumer_generated **quarantined**
sc_downgrade [timeout] **quarantined**