Fix mysql_* providers for MariaDB >= 11.4

[cruelsmith]

Summary

Fixes the broken providers for MariaDB >= 11.4 as #1645 missed to cleanup the commands mysql_raw in the sub providers.

Additional Context

Add any additional context about the problem here.

• Root cause and the steps to reproduce. (If applicable)
• Thought process behind the implementation.

Related Issues (if any)

Closes #1672
Closes #1685 as duplicate of #1672
Obsolete #1689 as issue as already fixed with #1645 and this cleanup.

Checklist

• 🟢 Spec tests.
• 🟢 Acceptance tests.
• Manually verified. (via puppet on RHEL9 with MariaDB 12.3)

[SimonHoenscheid]

@jst-cyr Can your team please merge this and cut a new release?

[jst-cyr]

@jst-cyr Can your team please merge this and cut a new release?

Thanks for the ping @SimonHoenscheid ! I do have this very high on the prioritized list with engineering, but a lot of Puppet 9 prep work is currently ahead of it (and some other module PRs on mysql and postgresql). I think the next step is to have engineering run the acceptance tests and provide feedback.

[jst-cyr]

CI test run created: #1724

[jst-cyr]

CI test results (PR #1724)

All 12 acceptance test jobs failed, across every OS/version in the matrix (CentOS-8, Debian-11, Debian-12, RedHat-7/8/9/10, Rocky-8, SLES-12/15, Ubuntu-18.04/20.04/22.04). Spec tests passed.

What happened

Every job failed with the same signature, in mysql_grant_spec.rb and mysql_user_spec.rb:

Error: Could not prefetch mysql_user provider 'mysql': Command mysql_client is missing
Error: Could not prefetch mysql_grant provider 'mysql': Command mysql_client is missing
Error: Could not prefetch mysql_database provider 'mysql': Command mysql_client is missing

Tracing further, the underlying shell error is:

bash: /usr/bin/mysql: No such file or directory

27 examples failed on most platforms (25 on Ubuntu-22.04), all cascading from this same "Command mysql_client is missing" prefetch failure — the mysql, mysql_user, mysql_grant, and mysql_database providers are all marked "not suitable" because the mysql binary can't be found on the test node.

Possible root cause

The shared parent provider class (lib/puppet/provider/mysql.rb) declares:

commands :mysql_client => 'mysql'

as a mandatory commands entry (not optional_commands). Puppet's provider suitability check fails a provider outright if any mandatory command binary can't be resolved — this happens before any of the runtime fallback logic in self.mysql_raw (which otherwise prefers mariadb_client on newer MariaDB) ever gets a chance to run.

This PR's changes only remove the redundant, duplicate commands mysql_raw: 'mysql' declarations from the individual provider subclasses (mysql_database, mysql_grant, mysql_plugin, mysql_user) and commands mysqld: 'mysqld' from mysql_datadir, relying on the parent class's declarations instead. The parent's mandatory mysql_client requirement itself is untouched by this PR.

The test nodes in this run appear to lack a mysql-named binary entirely (consistent with newer MariaDB releases, e.g. >= 11.4, that ship only mariadb-named client binaries) — which is the same scenario this PR's title references. All 12 platforms failed identically, so this doesn't appear to be OS-specific.

[jst-cyr]

@cruelsmith : I've linked to acceptance test results and provided some diagnosis of the errors that were run through Claude. Hopefully this helps as some feedback to look for what's going on here!

[cruelsmith]

@jst-cyr Thanks for taking care of that but the puppet DSL for providers and acceptance test are not my expertise.

I would suggest to try the acceptance test again with the changes from #1705 as it fixes mysqld_version_string which has been also used by the changes from #1580 and it also broken since then for the first puppet run.

Also the suggestion from Claude to try to use optional_commands instead was mentioned in #1645 (comment). I would guess we would then need a define statement to ensure one of the two binaries must exist to mark that provider suitable.
But if that is really the issue can only answered by someone with deeper puppet DSL / acceptance test knowledge.

[jst-cyr]

I'm going to raise the priority for us reviewing #1705 and treat it as a prereq for this PR.