release-23.2: opt: add lock operator

[blathers-crl]

Backport 2/2 commits from #111662 on behalf of @michae2.

/cc @cockroachdb/release

---

execbuilder: change error message to match PostgreSQL

Release note (sql change): Change the following error message:

statement error cannot execute FOR UPDATE in a read-only transaction

to this to match PostgreSQL:

statement error cannot execute SELECT FOR UPDATE in a read-only transaction

opt: add lock operator

Add a new implementation of SELECT FOR UPDATE and SELECT FOR SHARE
statements. Instead of locking during the initial row fetch, this new
implementation constructs a Lock operator on the top of the query plan
which performs the locking phase using a locking semi-join lookup.

During optbuilder we build plans with both Lock operators and
initial-row-fetch locking. During execbuilder we decide which
implementation to use based on the isolation level and whether
optimizer_use_lock_op_for_serializable is set. If the new
implementation is chosen, Lock operators become locking
semi-LookupJoins.

In some cases these new plans will have superfluous lookup joins. A
future PR will optimize away some of these superfluous lookup joins.

Fixes: #57031, #75457

Epic: CRDB-25322

Release note (sql change): Add a new session variable,
optimizer_use_lock_op_for_serializable, which when set enables a new
implementation of SELECT FOR UPDATE. This new implementation of
SELECT FOR UPDATE acquires row locks after any joins and filtering,
and always acquires row locks on the primary index of the table being
locked. This more closely matches SELECT FOR UPDATE behavior in
PostgreSQL, but at the cost of more round trips from gateway node to
replica leaseholder.

Under read committed isolation (and other isolation levels weaker than
serializable) we will always use this new implementation of SELECT FOR UPDATE regardless of the value of
optimizer_use_lock_op_for_serializable to ensure correctness.

---

Release justification: part of the read committed commitment for 23.2.

[blathers-crl]

Thanks for opening a backport.

Please check the backport criteria before merging:

• Patches should only be created for serious issues or test-only changes.
• Patches should not break backwards-compatibility.
• Patches should change as little code as possible.
• Patches should not change on-disk formats or node communication protocols.
• Patches should not add new functionality.
• Patches must not add, edit, or otherwise modify cluster versions; or add version gates.

If some of the basic criteria cannot be satisfied, ensure that the exceptional criteria are satisfied within.

• There is a high priority need for the functionality that cannot wait until the next release and is difficult to address in another way.
• The new functionality is additive-only and only runs for clusters which have specifically “opted in” to it (e.g. by a cluster setting).
• New code is protected by a conditional check that is trivial to verify and ensures that it only runs for opt-in clusters.
• The PM and TL on the team that owns the changed code have signed off that the change obeys the above rules.

Add a brief release justification to the body of your PR to justify this backport.

Some other things to consider:

• What did we do to ensure that a user that doesn’t know & care about this backport, has no idea that it happened?
• Will this work in a cluster of mixed patch versions? Did we test that?
• If a user upgrades a patch version, uses this feature, and then downgrades, what happens?

[cockroach-teamcity]

This change is 

[DrewKimball]

Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @mgartner, @michae2, and @msirek)

[michae2]

@mgartner this is the last of the read committed functionality. It just missed the branch cut by about an hour, so I had to backport. PTAL when you get the chance.

[mgartner]

LGTM

In some cases these new plans will have superfluous lookup joins. A
future PR will optimize away some of these superfluous lookup joins.

Is this planned for 23.2 or later?

[michae2]

Is this planned for 23.2 or later?

The work hasn't been done yet, but maybe 23.2 if I get to it and the backport is small enough and you think it's a good idea.