innobase/{lock0lock,dict0dict}: add noexcept to lock/unlock methods

[MaxKellermann]

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

Description

MariaDB is compiled with C++ exceptions enabled, and that disallows
some optimizations (e.g. the stack must always be unwinding-safe). By
adding noexcept to functions that are guaranteed to never throw,
some of these optimizations can be regained. Low-level locking
functions that are called often are a good candidate for this.

This shrinks the executable a bit (tested with GCC 14 on aarch64):

text	  data	   bss	   dec	   hex	filename

24448910 2436488 9473185 36358583 22ac9b7 build/release/sql/mariadbd
24448474 2436488 9473601 36358563 22ac9a3 build/release/sql/mariadbd

(See #3529 (comment))

Release Notes

No runtime effect.

How can this PR be tested?

No runtime effect.

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.

[dr-m]

Thank you! I knew that noexpect was introduced in C++11, but I didn’t study what it actually does. I was assuming that it mainly exists for documentation or API safety purposes, similar to override or private. There are indeed few throw in our code base, I guess it would be mostly an implicit std::bad_alloc in the few memory allocations that do not use a custom allocator. In InnoDB there could be a few uses of STL collections that would use a default allocator. Anywhere else, it could make sense to add noexpect.

I think that this one needs to be rebased on the 10.6 branch, where the locking primitives were refactored and which most our customers using, as part of the MariaDB Enterprise Server offering. Can you also file a MDEV for this?

[MaxKellermann]

I created https://jira.mariadb.org/browse/MDEV-34973 and rebased the PR on branch 10.6

[MaxKellermann]

I could not build the 10.5 branch because:

$ git submodule update --init --recursive
fatal: transport 'file' not allowed
fatal: Fetched in submodule path 'storage/columnstore/columnstore', but it did not contain 9f905c07b9c5ba68590a7cec24e71859d4082d56. Direct fetching of that commit failed.

... and my bet that I could just fix the merge conflict and be done didn't work out.

[MaxKellermann]

Hooray for try'n'error with CI logs. It now builds.