Document how to customize MaxScale's systemd unit file

Systemd supports "drop-in" unit files:

Along with a unit file foo.service, a "drop-in" directory foo.service.d/ may exist. All files with the suffix ".conf" from this directory will be parsed after the unit file itself is parsed. This is useful to alter or add configuration settings for a unit, without having to modify unit files. Drop-in files must contain appropriate section headers. For instantiated units, this logic will first look for the instance ".d/" subdirectory (e.g. "foo@bar.service.d/") and read its ".conf" files, followed by the template ".d/" subdirectory (e.g. "foo@.service.d/") and the ".conf" files there. Moreover for units names containing dashes ("-"), the set of directories generated by truncating the unit name after all dashes is searched too. Specifically, for a unit name foo-bar-baz.service not only the regular drop-in directory foo-bar-baz.service.d/ is searched but also both foo-bar-.service.d/ and foo-.service.d/. This is useful for defining common drop-ins for a set of related units, whose names begin with a common prefix. This scheme is particularly useful for mount, automount and slice units, whose systematic naming structure is built around dashes as component separators. Note that equally named drop-in files further down the prefix hierarchy override those further up, i.e. foo-bar-.service.d/10-override.conf overrides foo-.service.d/10-override.conf.

In addition to /etc/systemd/system, the drop-in ".d/" directories for system services can be placed in /usr/lib/systemd/system or /run/systemd/system directories. Drop-in files in /etc take precedence over those in /run which in turn take precedence over those in /usr/lib. Drop-in files under any of these directories take precedence over unit files wherever located. Multiple drop-in files with different names are applied in lexicographic order, regardless of which of the directories they reside in.

https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Description

If a user needs to customize MaxScale's systemd unit file, then it is generally preferable to add a "drop-in" unit file, rather than modifying the primary unit file. The reason is that the primary unit file is overwritten every time the package is upgraded, so any customizations would be lost.

For example, to give MaxScale an infinite systemd timeout, you could execute the following commands:

sudo tee /etc/systemd/system/maxscale.service.d/timeoutsec.conf <<EOF

[Service]

TimeoutStartSec=0

TimeoutStopSec=0

EOF

sudo systemctl daemon-reload

Similar information is documented for MariaDB Server in this section:

https://mariadb.com/kb/en/library/systemd/#configuring-the-systemd-service

Maybe MaxScale's "Configuration Guide" could have a similar section on configuring systemd?:

https://mariadb.com/kb/en/mariadb-maxscale-23-mariadb-maxscale-configuration-usage-scenarios/

https://mariadb.com/kb/en/mariadb-maxscale-24-mariadb-maxscale-configuration-guide/