sql: rollback to savepoint broken in mixed-version (19.2/20.1) clusters

[andreimatei]

A 20.1 node rolling back to a savepoint doesn't affect request evaluation on 19.2 nodes, as 19.2 doesn't understand about ignored sequence number ranges. This means that reads served by old nodes will still return values that should have been rolled back, and they'll also commit them.
It's not the highest impact bug in the world seems it seems dubious to start using savepoints in a mixed-version cluster since some nodes would error out, but if you do start using it it's not good.

I guess we should gate execution of savepoints on a cluster version. One problem is with rolling back to the cockroach_restart savepoint which, in 20.1 nodes, uses the same ignored seqnum mechanism when the rollback happens from the Open state. That's a bit of an edge case, as generally one rolls back to cockroach_restart after a retriable error (so, not from the Open state).

Repro below. t is a table with the leaseholder on 19.2, t2 has the leaseholder on 20.1. After a rollback, writes to the latter go away, but not to the former.

root@localhost:26259/defaultdb> begin;
BEGIN
root@localhost:26259/defaultdb  OPEN> savepoint a;
SAVEPOINT
root@localhost:26259/defaultdb  OPEN> insert into t(x) values (1);
INSERT 1
root@localhost:26259/defaultdb  OPEN> insert into t2(x) values (1);
INSERT 1
root@localhost:26259/defaultdb  OPEN> select * from t;
  x
-----
  1
(1 row)
root@localhost:26259/defaultdb  OPEN> select * from t2;
  x
-----
  1
(1 row)
root@localhost:26259/defaultdb  OPEN> rollback to savepoint a;
ROLLBACK
root@localhost:26259/defaultdb  OPEN> select * from t;
  x
-----
  1
(1 row)
root@localhost:26259/defaultdb  OPEN> select * from t2;
  x
-----
(0 rows)

[knz]

oh I know what to do with this