Crash on ROLLBACK of DELETE or UPDATE in a ROW_FORMAT=COMPRESSED table

jeanfrancois.gagne provided a copy of a page of a ROW_FORMAT=COMPRESSED page on which an attempt to execute the following:

BEGIN;

DELETE FROM t WHERE pk=123;

ROLLBACK;

would lead to the following crash:

2023-03-20 11:09:00 0x7f427c2026c0  InnoDB: Assertion failure in file /mariadb/10.6/storage/innobase/row/row0umod.cc line 130

InnoDB: Failing assertion: !dummy_big_rec

InnoDB: We intentionally generate a memory trap.

InnoDB: Submit a detailed bug report to https://jira.mariadb.org/

…

#7  0x0000558b2197f2e3 in ut_dbg_assertion_failed (expr=expr@entry=0x558b20cfd8b8 "!dummy_big_rec", file=file@entry=0x558b20d6ea78 "/mariadb/10.6/storage/innobase/row/row0umod.cc", line=line@entry=130) at /mariadb/10.6/storage/innobase/ut/ut0dbg.cc:60

#8  0x0000558b2194a7fb in row_undo_mod_clust_low (node=node@entry=0x7f422002d698, offsets=offsets@entry=0x7f427c200178, offsets_heap=offsets_heap@entry=0x7f427c200170, heap=0x7f4220031b10, sys=sys@entry=0x7f427c2001d3 "|B\177", thr=thr@entry=0x7f422004faf0, mtr=<optimized out>, mode=<optimized out>) at /mariadb/10.6/storage/innobase/row/row0umod.cc:130

The reason for this crash is a misguided check in btr_cur_update_in_place() that unnecessarily causes btr_cur_pessimistic_update() to be invoked during the ROLLBACK operation.

Back in 2005, I specifically designed the ROW_FORMAT=COMPRESSED format in such a way that a delete or the rollback of a delete would always succeed, as would purging the history of a delete-marked record. The "deleted" as well as the "freed" flags are stored in a bit in the dense page directory at the end of the compressed page. This is the reason why the uncompressed page size is limited to 16384 bytes when using ROW_FORMAT=COMPRESSED. The clustered index fields DB_TRX_ID, DB_ROLL_PTR will be stored in uncompressed format right before the page directory. Thus, both a DELETE and ROLLBACK can be executed without touching any compressed data.