73475: kvclient: cleanup legacy TxnHeartbeating field r=andreimatei a=andreimatei

This field indicates whether the txn heartbeat loop started. 21.2 is not
reading this field; it's only writing it for compatibility with 21.1.
So, it's no longer needed since we're working towards 22.1.

Release note: None

73478: rangecache: fix a span use-after-Finish r=andreimatei a=andreimatei

Lookups of range descriptors use a form of pretty unusual unstructured
concurrency: a request spawns a goroutine that might outlive it (in case
the request is canceled), but at the same time the goroutine wants to be
part of the same trace as the request. Before this patch, the goroutine
was responsible for forking the request's span asynchronously. This was
pretty broken because the request's span might be finished by the time
it's forked. This is a use-after-Finish, and I'm trying to stop
tolerating such uses. This patch fixes it by forking the span
synchronously.

Release note: None

73494: sql: actually deflake TestSavepoints r=nvanbenschoten a=nvanbenschoten

This PR rolls back #73388 and reworks the fix for #70220. #73388 was an incorrect fix because the test relies on the progress table being updated in the same transaction as the rest of the SQL logic. This ensures that progress updates are rolled back when the rest of the transaction is rolled back. I didn't catch this in the initial PR because I missed the fact that the test had been skipped on `master`, so the test appeared to be passing with the change. When I then tried to backport the change in #73492, CI caught the mistake.

The PR then deflakes `TestSavepoints` by increasing the lock timeout significantly (from 1ms to 100ms) in the `rollback_after_lock_timeout` subtest. The test was flaky because after the transaction hits a lock timeout error, it performs an async rollback. If this async rollback hasn't grabbed latches by the time the next txn retry (with a different txn ID) finishes waiting out the lock_timeout when attempting to write to its progress, a lock timeout error would be thrown. This commit makes this extremely unlikely by increasing the lock timeout from 1ms to 100ms. With this new timeout, I've never seen the test flake under stress.

73515: roachtest: fix pgjdbc unexpected pass for ArrayTest in 22.1 r=rafiss a=ZhouXing19

fixes #73298

Release note: None

73525: kv/kvnemesis: skip TestKVNemesisSingleNode r=irfansharif a=irfansharif

Refs: #73373

Reason: flaky test

Generated by bin/skip-test.

Release justification: non-production code changes

Release note: None

Co-authored-by: Andrei Matei <andrei@cockroachlabs.com>
Co-authored-by: Nathan VanBenschoten <nvanbenschoten@gmail.com>
Co-authored-by: Jane Xing <zhouxing@uchicago.edu>
Co-authored-by: irfan sharif <irfanmahmoudsharif@gmail.com>