lock_rec_unlock_unmodified<CELL>() can release a stale per-cell latch after a concurrent lock_sys.rec_hash resize

In storage/innobase/lock/lock0lock.cc, lock_release_on_prepare_try() calls lock_rec_unlock_unmodified<CELL>() while holding a per-cell hash-latch acquired from a cell address computed before the call.

On a secondary index, lock_rec_unlock_unmodified<CELL>() drops the cell latch and lock_sys.latch before calling lock_sec_rec_some_has_impl().
It then re-acquires the lock_sys.latch in shared mode, recomputes the cell address and tries to latch the cell with the newly computed address.
A concurrent lock_sys_t::hash_table::resize() (lock_sys.rec_hash grows with the buffer pool resize) during the lock_sys.rd_unlock() window, reallocates the cell array so the cell and its latch move.
On return true from the lock_rec_unlock_unmodified<CELL>(), the caller's latch may be stale.
The subsequent caller's latch->release() then may be invalid.

A one-line fix is to replace, in lock_release_on_prepare_try() on the lock_rec_unlock_unmodified<CELL>() success path:

latch->release();

with

lock_sys_t::hash_table::latch(lock_sys.rec_hash.cell_get(fold))->release();

or have lock_rec_unlock_unmodified() report the cell/latch it holds on success, to avoid another lookup.