sql: validating FK constraint uses extremely slow hash join

[thoszhang]

Currently VALIDATE CONSTRAINT for foreign keys performs a hash join on the source and target columns, which can be extremely slow. SCRUB has a much faster implementation of fk validation that uses a merge join: I ran the SCRUB fk validation on a tpcc-100 table on a roachprod cluster, and it only took a few seconds, compared to >1 hour (before I killed it) for the query that would be used in VALIDATE CONSTRAINT. We should try to reimplement VALIDATE CONSTRAINT to use the same approach as SCRUB.

There's no straightforward way to do this via SQL because null values need to be handled correctly, which requires an ON clause that contains a bunch of a=b OR (a IS NULL AND b IS NULL) clauses (as in the current implementation, https://github.com/cockroachdb/cockroach/blob/master/pkg/sql/check.go#L115-L121). The way SCRUB gets around this is to create a plan that uses a merge join, and then have a separate step to set NullEquality to true on all MergeJoinerSpecs in the plan.

This will partially address #32118, but the unrelated issue of long transactions restarting still needs to be fixed.

[thoszhang]

Some of the above no longer applies after the new changes to foreign key matching (#20305). We need to rewrite the FK validation query to conform to the new matching semantics.

I believe that the correct queries will not require clauses of the form a=b OR (a IS NULL AND b IS NULL), so they will automatically use a merge join without further intervention.