Fix WITHOUT OVERLAPS multirange with location replication

Hi Hackers,

Andres reported that a WITHOUT OVERLAPS replica identity using
multiranges can update/delete the wrong row, because a recheck is
needed.[0] This patch fixes that problem by performing a recheck when
the scan indicates one is needed.

RelationFindReplTupleByIndex() and
RelationFindDeletedTupleInfoByIndex() skipped the tuples_equal() check
whenever the scan used the primary key or replica identity index,
assuming any match is exact. But a GiST index on a multirange is
lossy: two multiranges with the same bounding range, like {[1,5)} and
{[1,2),[3,5)}, look the same to the index. Now we recheck the
candidate whenever the scan sets xs_recheck, like
check_exclusion_or_unique_constraint() does. Btree and range-type GiST
indexes never set it, so they keep the fast path. When we do recheck,
we compare only the key columns, since those are all the search slot
has (and we only look up that bitmap if we need it).

The second function is used for conflict detection with
retain_dead_tuples. There the bug can't modify the wrong row, but it
can report update_deleted (blaming the transaction that deleted an
unrelated row) instead of update_missing.[1]

The patch adds a TAP test to 034_temporal.pl using two multiranges
with the same bounding range.

[0] https://www.postgresql.org/message-id/kcyaok346iwocfdourf2oojgtz7ggxmh2ugis7qqhggs4qfzc2%40cu6pkox4rfwp
[1] https://www.postgresql.org/message-id/e5nb5jbus2oa3pffmlo7pdvdckmchd54tqld4k3n6huyg5xxqn%407rounyvufjx6

Yours,

--
Paul ~{:-)
pj(at)illuminatedcomputing(dot)com