Re-enable them later when investigated enough.

Fixes Lintian complaints:
  E: galera-4: sharedobject-in-library-directory-missing-soname
     usr/lib/libgalera_smm.so
  W: galera-4: breakout-link usr/lib/galera/libgalera_smm.so ->
     usr/lib/libgalera_smm.so

Also fix typo introduced in previous commit.

Also sync all other relevant changes done in debian/ upstream.

Update to upstream version '26.4.7'
with Debian dir 85a214e64168b4da9081e3eb8b18507bdbb211f4

Update to upstream version '26.4.6'
with Debian dir c4f28eaac4089a70f85e1ea88ccbda48bb8d7721

The salsa-ci.yml contains references to files that when changed "upstream"
mandate changes downstream so that the pipelines will work again.

Also refactor and fix syntax issues as has been done in the mariadb-10.5
salsa-ci.yml file.

Extend CI with job 'galera-3 stretch to galera-4 upgrade'.

This helps avoid any annoying timeouts in tests, e.g.

  0%: Checks: 2, Failures: 0, Errors: 2
  galerautils/tests/gu_lock_step_test.c:53:E:gu_lock_step:gu_lock_step_test:0: (after this point) Test timeout expired
  galerautils/tests/gu_lock_step_test.c:122:E:gu_lock_step:gu_lock_step_race:0: (after this point) Test timeout expired

Also inline the double if statements to make them more readable.

Changes-By: lintian-brush
Fixes: lintian: upstream-metadata-missing-bug-tracking
See-also: https://lintian.debian.org/tags/upstream-metadata-missing-bug-tracking.html

The riscv64 builders on Launchpad seem very slow. Attempt to fix the build
failures by doubling the test timeout on riscv64, similar to how it was
done on mipsel.

If ifneg+filter structure as it seems to be the only way to check if
a string is one of multiple options.

https://www.gnu.org/software/make/manual/html_node/Text-Functions.html#Text-Functions
https://man7.org/linux/man-pages/man1/dpkg-architecture.1.html#TERMS

- Drop legacy hardening wrapper stanza DEB_BUILD_HARDENING
- Improved documentation that is unified with section upstream

- Remove copyright reference to directory no longer in Galera 4
- Update to Debian Policy version 4.5.0

Update to upstream version '26.4.5'
with Debian dir 94891662d1484dd4ce9b7be4edefaa14b7879139

Fix systemd unit and start script.

See merge request mariadb-team/galera-4!2

The start script does not work on Debian because the path for config
file is not correct.
The environment definition in the systemd unit file is redundant (and
problematic on Debian) with config file definition in the bash start
script (garb-systemd).
Also, the bash script needed some linting IMO.
Finally, Alias should not be used in systemd unit file and static
symlink should be deployed at postinstall instead.
See https://wiki.debian.org/Teams/pkg-systemd/Packaging#systemd_unit_files_naming_and_installation

Satisfies Lintian notice:
https://lintian.debian.org/tags/rules-requires-root-missing.html

Verified with 'hardening-check -v /usr/bin/garbd'.

Before:
/usr/bin/garbd:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
	unprotected: memmove
	unprotected: snprintf
	unprotected: memcpy
	unprotected: strncpy
	unprotected: strncat
	unprotected: poll
	unprotected: memset
	unprotected: strcpy
	protected: sprintf
	protected: snprintf
	protected: memcpy
	protected: fprintf
	protected: vsnprintf
	protected: syslog
	protected: strcat
 Read-only relocations: yes
 Immediate binding: no, not found!
 Stack clash protection: unknown, no -fstack-clash-protection instructions found
 Control flow integrity: unknown, no -fcf-protection instructions found!

After:
/usr/bin/garbd:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
	unprotected: strncpy
	unprotected: poll
	unprotected: memset
	unprotected: strcpy
	unprotected: strncat
	unprotected: memmove
	unprotected: snprintf
	unprotected: memcpy
	protected: syslog
	protected: strcat
	protected: snprintf
	protected: memcpy
	protected: vsnprintf
	protected: fprintf
	protected: sprintf
 Read-only relocations: yes
 Immediate binding: yes
 Stack clash protection: unknown, no -fstack-clash-protection instructions found
 Control flow integrity: unknown, no -fcf-protection instructions found!

Lintian no longer complains about this, on the contrary Lintian states
that it is now unused.

Copied from Salsa-CI source at
https://salsa.debian.org/salsa-ci-team/pipeline/blob/master/salsa-ci.yml

See also
https://salsa.debian.org/salsa-ci-team/pipeline/tree/master#enabling-the-pipeline-for-tags