MDEV-38814 Reduce pessimistic update fallbacks

[iMineLink]

Alternative PR to address MDEV-38814.
This attempt, compared to #4887, tries to address the issue at a higher level, changing the optimistic rejection and pessimistic fallback handling in InnoDB btr updates, without changing locking rules.

This PR is composed of 3 commits:

1. The first commit adds debug-only counters to monitor the pessimistic update fallbacks and respective index lock upgrades in the current code, as verified in the innodb.index_lock_upgrade test.
2. The second commit avoids in btr_cur_optimistic_update() that a freshly split page, interested by an update that is growing a record's size, becomes victim of underflow due to its post-update size being less than BTR_CUR_PAGE_COMPRESS_LIMIT(index) (to trigger potential page merge in the pessimistic path); Do trigger underflow in such cases only for updates that shrink the record size; This reduces to 0 the underflows in the test (which only issues NULL to not-NULL updates) and respective (failed) page merge attempts.
3. The last commit enforces the reorganization limit BTR_CUR_PAGE_REORGANIZE_LIMIT in btr_cur_pessimistic_update(), avoiding btr_cur_insert_if_possible() calls when the page's post-reorganize free space is below BTR_CUR_PAGE_REORGANIZE_LIMIT for uncompressed pages, letting the code fall through the pessimistic insert path; This reduces the overflows and reorganizations in the test, at the cost of one extra page split.

This is opened as a draft to get some CI coverage and allow initial discussion.
I believe this PR addresses the MDEV's issue in a better way than the previous attempt, trying to optimize index maintenance operations.

Discussion points:

1. Is it OK to make only record shrinking UPDATE(s) pay the price of potential page merge through underflow? I think so, it seems in any case that all the previous merge attempts failed in the test. Is there a mismatch between the btr_cur_optimistic_update() test and the effective page merge logic? I have still to verify current behavior on record shrinking/same-size updates.
2. Both changes in optimistic and pessimistic update paths tend to create sparser trees, reducing merge attempts (even if they all failed in the test) and increasing split attempts. Can this be detrimental in some cases?

I will continue testing the behavior of this branch and possibly add other UPDATE patterns in the mix (same record size, shrinking record, compressed pages, varying page size)

[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.}