59863: cli/zip: issue per-node requests concurrently r=tbg a=knz

Requested by @ajwerner and @andreimatei 
First commit from  #64081.

Release note (cli change): `cockroach debug zip` now attempts to pull
data from multiple nodes concurrently, up to 15 nodes at a time. This
change is meant to accelerate the data collection when a cluster
contains multiple nodes. This behavior can be negated with the new
command-line flag `--sequential`.

63800: kv: properly handle intent pushes to synthetic timestamps r=nvanbenschoten a=nvanbenschoten

This commit reworks the timestamp that pushers use when pushing intents
to synthetic timestamps. Usually, as of #59086, a pusher limits the
timestamp that it pushes conflicting intents to using the local HLC
clock. This is based on the assumption that it will be able to ignore
any intent above the local HLC clock's reading using observed timestamps
and a local uncertainty limit.

However, this argument only holds if we expect to be able to use a local
uncertainty limit when we return to read the pushed intent. Notably,
local uncertainty limits can not be used to ignore intents with
synthetic timestamps that would otherwise be in a reader's uncertainty
interval. This is because observed timestamps do not apply to
intents/values with synthetic timestamps. So if we know that we will be
pushing an intent to a synthetic timestamp, we don't limit the value to
a clock reading from the local clock.

This came out of some exploration of kvnemesis. I don't think this was
actually causing an issue, but it seemed like a potential source of an
infinite push + conflict loop.

Release note (bug fix): Read-write contention on GLOBAL tables no longer
has a potential to thrash without making progress.

64017: sql: add test TestAlterRegionalByRowEnclosingRegionAddDrop r=arulajmani a=arulajmani

See individual commits for details. 

There's more test scenarios I want to add where we sandwich an ADD/DROP region inside of an ALTER to REGIONAL BY ROW/or an operation on one of these tables, but here's a start. The error messages aren't wrapped yet, so they may appear a bit ugly in the jobs table. What this test ensures, which I think is quite valuable, is that the rollback is fine and no manual cleanup is required.

Co-authored-by: Raphael 'kena' Poss <knz@thaumogen.net>
Co-authored-by: Nathan VanBenschoten <nvanbenschoten@gmail.com>
Co-authored-by: arulajmani <arulajmani@gmail.com>