UPDATE IGNORE in READ COMMITTED with long unique or without overlaps doesn't work

MDEV-37199 fixes the case of in-server UNIQUE constraints (USING HASH and WITHOUT OVERLAPS) in case of READ COMMITTED transaction isolation mode by checking the constraint after the row inserted or updated.

In case of INSERT IGNORE or UPDATE IGNORE the last row operation must be reverted for the statement to continue executing on further rows. This was implemented as a delete_row or update_row on the current (last inserted or updated) row.

Unfortunately, if the update operation modifies PRIMARY KEY, InnoDB internally implements it as a delete+insert, but keeps the "current" row cursor on the deleted row, not on the inserted one. Thus an attempt to revert an update trips an assert inside InnoDB, which sees an update of a deleted row.

As a rare use case a combination of READ COMMITTED, UPDATE IGNORE that modifes the PRIMARY KEY, and in-server UNIQUE constraints (USING HASH or WITHOUT OVERLAPS) was split out of MDEV-37199 and will be fixed here.

Similar case — update implemented as delete+insert — happens in partitioning when the partitioning key is updated. Causes the same bug.