MDEV-28800 SIGABRT due to running out of memory for InnoDB locks

[mariadb-DebarunBanerjee]

• The Jira issue number for this PR is: MDEV-28800

Description

This regression is introduced in 10.6 by following commit. commit 898dcf9
(Cleanup the lock creation)
It removed one important optimization for lock bitmap pre-allocation. We pre-allocate about 8 byte extra space along with every lock object to adjust for similar locks on newly created records on the same page by same transaction. When it is exhausted, a new lock object is created with similar 8 byte pre-allocation. With this optimization removed we are left with only 1 byte pre-allocation. When large number of records are inserted and locked in a single page, we end up creating too many new locks almost in n^2 order.

Fix-1: Bring back LOCK_PAGE_BITMAP_MARGIN for pre-allocation.

Fix-2: Use the extra space (40 bytes) for bitmap in trx->lock.rec_pool.

Release Notes

Fixes a regression in 10.6 - Server abort due to running out of lock memory while inserting large number of rows using INSERT INTO SELECT statement.

How can this PR be tested?

./mtr innodb.lock_memory

Basing the PR against the correct MariaDB version

• This is a new feature and the PR is based against the latest MariaDB development branch.
• This is a bug fix and the PR is based against the earliest maintained branch in which the bug can be reproduced.

PR quality check

• I checked the CODING_STANDARDS.md file and my PR conforms to this where appropriate.
• For any trivial modifications to the PR, I am ok with the reviewer making the changes themselves.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[dr-m]

Thank you, this looks good to me.