Replace using of internal fmt lib API with public API

[keeper]

Related MDEV: https://jira.mariadb.org/browse/MDEV-31963

Description

The commit cd5808eb introduced a union as a storage for the format argument passed to the internal API fmt::detail::make_arg. This was done to solve the issue that the internal API no longer accepted temporary variables.

However, it's generally better to avoid using internal APIs, as they are more likely to have breaking changes in the future. Instead, we can use the public API fmt::dynamic_format_arg_store to dynamically build the argument list. This API accepts temporary variables, and its behavior is more stable than the internal API.

How can this PR be tested?

• MTR tests passed

Basing the PR against the correct MariaDB version

• This is a new feature and the PR is based against the latest MariaDB development branch.

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.

Copyright

All new code of the whole pull request, including one or several files that are either new files or modified ones, are contributed under the BSD-new license. I am contributing on behalf of my employer Amazon Web Services, Inc.

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

[grooverdan]

Nice! Thanks for noticing.

Can you rebase this back to 10.11?

Are the libfmt versions supporting this public API back to the original minimum supported (v 8 something I think)?

FYI @ZhongRuoyu

[ZhongRuoyu]

Thanks! Logic looks good to me.

fmtlib/fmt@6012dc9 seems to be the commit that introduced fmt::dynamic_format_arg_store. It was then released in 6.2.0, so compatibility-wise it should be okay.

Though, for consistency, I believe cmake/libfmt.cmake needs to be updated too.

[vuvova]

right, let's fix cmake/libfmt.cmake too, it is supposed to test the availability of the API that the code is using, not availability of something completely different

[keeper]

Good catch, I'll make the change as soon as possible, thanks!

[keeper]

I've updated libfmt.cmake to reflect the changes. I also refactored it a bit so the source check can be reuse for both "system" and "bundled".

[grooverdan]

Note the validation of the bundled version is failing - https://buildbot.mariadb.org/#/builders/1/builds/50345

-- Performing Test LIBFMT_AVAILBLE
-- Performing Test LIBFMT_AVAILBLE - Failed
-- Performing Test LIBFMT_AVAILBLE
-- Performing Test LIBFMT_AVAILBLE - Failed
CMake Error at cmake/libfmt.cmake:60 (MESSAGE):
  Bundled libfmt library is not found or unusable
Call Stack (most recent call first):
  CMakeLists.txt:413 (CHECK_LIBFMT)
-- Configuring incomplete, errors occurred!
See also "/home/buildbot/tarball-docker/build/mkdist/CMakeFiles/CMakeOutput.log".
See also "/home/buildbot/tarball-docker/build/mkdist/CMakeFiles/CMakeError.log".

[keeper]

Looks like the bundled libfmt is not downloading after my refactor of libfmt.cmake, working on it now.

[keeper]

I mistake that ExternalProject_Add happens at configuration time and actually it's build time. In this case bundled libfmt is not available at the time thus CHECK_CXX_SOURCE_RUN() failed. I've reverted back the refactor and only updated the test code and it should works now.