Systemd hardening for mariadb (bug #1123021)

This MR improves the systemd-analyze security posture of the shipped mariadb.service and mariadb@.service unit templates by adding a set of hardening directives that should be low risk and not change normal MariaDB operation.

Changes included:

• ProtectKernelTunables=true, ProtectKernelModules=true, ProtectControlGroups=true
• RestrictRealtime=true
• LockPersonality=true
• RestrictNamespaces=true (documented as overrideable via a drop in)

These directives mainly reduce kernel/cgroup attack surface and block a few high impact process capabilities, while keeping MariaDB's existing runtime model intact, still unprivileged, same networking expectations, and the same filesystem access pattern as before.

Why not enable the stricter knobs (yet)

This MR intentionally avoids a few commonly suggested hardening options that have a history of causing regressions across distros and security setups:

• NoNewPrivileges=yes: can break SELinux domain transitions (init_t -> mysqld_t) and downstream integrations unless policy/kernel/systemd pieces line up.

  Ref: MDEV-10404 (and related issues).

• CapabilityBoundingSet= more aggressive capability changes, capability tuning has repeatedly caused startup failures on older systemd (for example EXIT_CAPABILITIES/218) and subtle auth/PAM breakage depending on SELinux policy and helper behavior. Refs: MDEV-36591, MDEV-36681, and PAM related history in MDEV-19878.

• PrivateDevices=yes: historically interacted badly with PAM SUID helper flows, and is often discussed alongside NoNewPrivileges side effects. Ref: MDEV-19878.

Those are the "high security gain, high blast radius" changes. For now this MR sticks to safe defaults.