Report database server version instead of client binary version

[JoshuaGoode]

Fixes

• New primary issue: Database Version reports the MySQL/MariaDB client, not the database server #318
• Related: https://core.trac.wordpress.org/ticket/58816
• Past attempt: Use mysql version from server rather than mysql --version #176

What changed

This updates runner environment collection so mysql_version comes from the database server when the runner can detect it safely.

Before this PR, mysql_version came from mysql --version. That is the local MySQL/MariaDB client binary, not necessarily the database server WordPress used for the test run.

The runner now asks the configured test database for SELECT VERSION() and stores the raw value. If that lookup cannot run safely, it leaves mysql_version empty and lets the existing reporter display Unknown.

I kept the existing mysql_version key for reporter compatibility. The field name is not ideal, but changing it would turn this into a runner + reporter data migration. I do not think we need that for this fix.

Why

As noted in #318, Host Test Results labels this value as "Database Version". When it starts with mysql Ver ..., it is showing the client program installed where the runner ran. That is not the server WordPress tested against.

This is important when comparing MySQL and MariaDB results, or when a failure only appears on one server version. The report should point to the server. The client, as is currently reported, is not useful.

Before this PR, generated env data could contain a value shaped like:

mysql Ver 15.1 Distrib 10.11.11-MariaDB

With this branch, a live submitted report shows:

11.4.8-MariaDB-log

History

There has been some previous work around this:

• Capture MySQL / MariaDB version when reporting environment details #29 requested
  MySQL/MariaDB version capture.
• Capture MySQL version, OS name and version in env reporting #32 added the current
  mysql_version path using mysql --version.
• Use mysql version from server rather than mysql --version #176 attempted to switch
  this field to SELECT VERSION().
• Fixes #209 restored the old
  client-version fetch after the server lookup reportedly broke tests. Unfotunately, no errors or details were provided about what broke.
• https://core.trac.wordpress.org/ticket/58816 is related MariaDB context and
  points back to this runner behavior.

This PR keeps the goal from #176. If detection fails, the runner reports Unknown through the existing reporter behavior. It should not block the test run, and it should not fall back to the client string as it's not appropriate or useful.

Avoiding previous issues

The prior attempt's lookup might have been too direct. A failed connection, failed query, missing mysqli, empty result row, or PHP 8.1+ mysqli exception could cause the test to fail.

This version has more guards

• It checks for mysqli support before using it.
• It turns mysqli strict reporting off for the lookup and restores the
  previous report mode afterward.
• It uses mysqli_real_connect() with parsed host, port, socket, and IPv6
  values.
• It checks the connection, query result, and returned row before using them.
• It frees the result and closes the connection.
• It returns an empty string on failure.

The generated logger in prepare.php is still self-contained but it now runs after the generated DB constants exist. The report fallback in functions.php uses the same behavior.

I intentionally did not add vendor parsing, normalization, a client-version field, reporter changes, or a replacement field. The key stays mysql_version and only the value it reports changes to be the proper server value.

Testing results

Live report proof:

https://make.wordpress.org/hosting/test-results/r62456/wpcombot-r62456-8-5-11-4-8-mariadb-log/

That report shows Database Version as 11.4.8-MariaDB-log, matching the server version returned by the live database rather than a mysql Ver ... client string.

Compare that to the client versions seen in the rest of the rest results run. The other results still show client values, so the difference is visible in context. https://make.wordpress.org/hosting/test-results/r62456/

Validation

After hosts update their runner checkout, I would spot-check the next few Host Test Results:

• "Database Version" should show raw server strings such as 8.0.x,
  10.x-MariaDB, or 11.x-MariaDB-log.
• New reports should not show mysql Ver ... under "Database Version".
• Environments where detection cannot run should still show Unknown.

Reminders / follow-up

• This should address the runner-side problem tracked in Core Trac:
  https://core.trac.wordpress.org/ticket/58816
  After this lands, that Trac ticket can be updated or closed as appropriate.
• Allow MySQL version to be passed using an environment variable #135 remains related
  for report-only flows that may need an explicit DB-version input when DB
  credentials are not available.
• README and Hosting handbook examples can be updated if this is merged.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: JoshuaGoode <verygoode@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[JoshuaGoode]

Noting that I have worked with two hosts to use my branch and they are actively reporting the database server version now.

May need testing in other setups but works in these live production envs.

• https://make.wordpress.org/hosting/test-results/r62462/pressablebot-r62462-8-5-11-4-8-mariadb-log/

• https://make.wordpress.org/hosting/test-results/r62462/wpcombot-r62462-8-4-11-4-8-mariadb-log/