Add support for Mariadb 11.x

[Marc-DRI]

Summary

Add support for Mariadb 11.x and use its mariadb and mariadbd binaries.

Additional Context

From Mariadb 11.0, mysql* names are deprecated in favor of mariadb* (cf. https://jira.mariadb.org/browse/MDEV-29582).
This pull request is:

• including commits from @OxCom, determining which binaries to use, depending on the mysqld_version facter
• fixing facters for mysql_version and mysqld_version whithin the MariaDB>11 context
• updating/adding tests for this new context

The initial PR #1626 causes an infinite loop in our case of fresh deployment, because facter is not properly initialized.

Related Issues

This pull request manages to fix #1580 .

[bastelfreak]

now we've two blocks for the same fact. Doesn't it make sense to unify it? What if mysql and mariadb is installed on the same server?

[neomilium]

Before MariaDB 11.0, using both mysql and mariadb was not supported by this module.
With this MariaDB 11.x support, it still dont work with both used at the same time but yes the facts collect can produce unexpected behavior.

As the two blocks contains de confine, I though that was the way to proceed.
https://www.puppet.com/docs/puppet/7/fact_overview.html#writing_facts_simple_resolutions-examples

Do you have some recommendation if you want to merge them?

[smortex]

This documentation feels weird. Inspecting various facts in the puppetlabs organization repositories, I don't see usage of confine with different prerequisites for the same facts, but a single fact with confinement that checks multiple conditions, e.g. https://github.com/puppetlabs/puppetlabs-java/blob/6319799bb310f824b18d9077905c46409535c977/lib/facter/java_default_home.rb#L16

It feels more natural for me to have a single Facter.add('mysql_version'), where the setcode logic attempts to get the expected value and return nil if none was found. A confinement does not even provide a short-circuit in this case, so we can probably go without it, i.e.

Facter.add('mysql_version') do
  setcode do
    mysql_ver = if Facter::Core::Execution.which('mysql')
                  Facter::Core::Execution.execute('mysql --version')
                elsif Facter::Core::Execution.which('mariadb')
                  Facter::Core::Execution.execute('mariadb --version')
                end
    mysql_ver.match(%r{\d+\.\d+\.\d+})[0] if mysql_ver
  end
end

So merging may make sense IMHO.

But beyond this consideration (and speaking as someone who does not use mysql nor mariadb), if mariadb and mysql are diverging one from the other and could be installed side by side on a single system, maybe it make sense to "fork" the puppetlabs-mysql module (puppet(labs)?-mariadb) just like mariadb forked mysql so that each module can track what the software they configure implement and provide a consistent interface and not some weak abstraction that may or may not work depending on the package you manage with the module?

[Marc-DRI]

Facters reworked and correctly working.
Thank you @smortex , code is much nicer !

[smortex]

Rubocop report some style issues, check the "Files changed" tab for details.

[Marc-DRI]

Should be better now...

[neomilium]

But beyond this consideration (and speaking as someone who does not use mysql nor mariadb), if mariadb and mysql are diverging one from the other and could be installed side by side on a single system, maybe it make sense to "fork" the puppetlabs-mysql module (puppet(labs)?-mariadb) just like mariadb forked mysql so that each module can track what the software they configure implement and provide a consistent interface and not some weak abstraction that may or may not work depending on the package you manage with the module?

@smortex I agree. It could be the right moment to split modules : mariadb and mysql.

@bastelfreak : What is your through about this split?

[neomilium]

Thinking it twice, there is no much interest to fork and no sufficient divergence to need a fork, so IMHO this PR could be accepted as is.

[smortex]

Looks good to me. I am not a member of this project so cannot trigger a CI run, @bastelfreak @alexjfisher can you please trigger it? Thanks!