MDEV-39040 log_sys.latch performance lost to PERFORMANCE_SCHEMA

[dr-m]

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

Description

log_sys.latch: Remove the PERFORMANCE_SCHEMA instrumentation. We already know that this is a very busy latch. All code paths where a shared log_sys.latch is being held should already be highly optimized. The few paths where an exclusive log_sys.latch is being held are known to be potentially problematic, but rare.

Release Notes

The PERFORMANCE_SCHEMA instrument wait/synch/rwlock/innodb/log_latch was removed.

How can this PR be tested?

On a quick Sysbench oltp_update_index run with

performance_schema_instrument=wait/synch/rwlock/%=on

I observed an 2.9% improvement on throughput. It could be more in other test scenarios.

Basing the PR against the correct MariaDB version

• This is a new feature or a refactoring, and the PR is based against the main 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.}

[iMineLink]

Compilation is broken with WITH_INNODB_EXTRA_DEBUG=ON, otherwise changes look good.
Maybe a comment could be left in the code explaining the reason of using srw_lock_low for the log_sys.latch, to ease reading?

[iMineLink]

LGTM.
The new srw_lock_debug_simple implementation is closely tracking srw_lock_debug.
I suppose that code is "cold" enough (from a development perspective) that duplication is acceptable.
Build errors are fixed.
Did not do any performance testing though, but less runtime bloat on a hot latch can be useful anyway if the PFS instrumentation was not useful anyway, in my opinion. If there are known issues being diagnosed via PFS on this latch, I would be a bit more wary to merge this.