Clarify that the $ensure parameter to systemd::tmpfiles only affects
the config file in /etc/tmpfiles.d itself, not the file or directories
specified in that config file.

This adds the ability to give per-path parameters when configuring
systemd-tmpfiles(8).  The $paths parameter to systemd::tmpfiles can
now be a hash of hashes, mapping from paths to hashes of parameters
overriding the parameters given directly to systemd::tmpfiles, e.g.

    systemd::tmpfiles {
        'smurf':
            type => 'd', mode => '0750', owner => 'gargamel',
            paths => {
                '/run/alldefaults' => {},
                '/run/file' => { 'type' => 'f', 'group' => 'smurfs' },
            };
    }

which will generate

    d  /run/alldefaults  0750  gargamel  -       -
    f  /run/file         0750  gargamel  smurfs  -

in /etc/tmpfiles.d/smurf.conf.

The original API, where you specify the $paths parameter as a simple
list of paths, or just a single string, is still available, as that is
easier to use for many simple cases.

Running systemd-tmpfiles(8) with the --remove option after modifying
the tmpfiles.d configuration, is apparently a bad idea.  There are
several packages distributing tmpfiles.d entries of type "D" that put
critical files in those directories.

E.g, Fail2Ban has a type "D" entry for /run/fail2ban.  Running
'systemd-tmpfiles --remove' will empty that directory, removing the
communication socket located there.  it then becomes impossible to
get status from the Fail2Ban daemon, or tell it to flush its logs
(which lograte(8) does).

Thus, change systemd::tmpfiles to use only the --create and --clean
options after it has updated config files in /etc/tmpfiles.d.

This adds a new definition systemd::tmpfiles, for managing config
files in /etc/tmpfiles.d, for systemd-tmpfiles(8).

The API is a bit limiting, in that while you can give it multiple
paths to be written to the same tmpfiles.d config file, they will all
share the same type, mode, owner, et.c.  Something more flexible would
be nice, but I'll need to think about that more.  As it is, the API at
least works for a common situation, where you only want to manage a
single path (typically a directory) at a time.

And there are workarounds: you can either specify raw lines/chunks to
add to the config file using the 'content' parameter, or you can use
multiple resources (which would create one config file per resource,
but the semantics is the same).  It would be nice to have a slightly
higher level API for this, but this will do for now.

In systemd::unit and systemd::unit_options, support a special syntax
in the hash of hashes for specifying comments on sections and on
individual options, where the comments get written to the systemd
unit file.

The syntax is to specify a key with a name prefixed with a hash (#)
sign.  The comment will be inserted just before the corresponding
section or option.  For example:

        options => {
            'Install' => { 'WantedBy' => 'multi-user.target' },
            'Service' => {
                'ExecStart' => '/bin/true'
                'User' => 'laureline',
                '#User' => "Don't run as Valerian",
            },
            '#Service' => [
                "This is a pretty silly service section,",
                "but we can test\nnewlines in the comment.",
            ],
        }

will generate

        [Install]
        WantedBy=multi-user.target

        # This is a pretty silly service section,
        # but we can test
        # newlines in the comment.
        [Service]
        ExecStart=/bin/true
        # Don't run as Valerian
        User=laureline

The idea is to be able to point out subtilities to readers of the
generated unit file, so someone looking at a configured system doesn't
have to go to the Puppet manifests to understand why something is done
in a specific way.

I'm not sure how useful this feature is, though.  Perhaps users will
be satisfied with having normal Puppet comments in the manifest source
code, and reading those.

Use 'contain systemd::daemon_reload' instead of 'include' in the
systemd::unit and systemd::unit_options definitions.  This allows
users to specify their unit/unit_options resources in dependencies,
and be sure that systemd has reloaded the new units before they
try to use them.

Mention that systemd::unit and systemd::unit_options automatically
includes and notifies systemd::daemon_reload, so users don't have to
do that themselves.

Have the error messages that unitfile.erb can raise include reference
to the resource (type and title) causing the error, so users can find
where they made the error.

When setting ensure = absent to systemd::unit_options, it doesn't
make sense for users to have to specify the options parameter.  But
it was a mandatory parameter, so they had to.  Fix that.

In systemd::unit_options, you can prefix an option name with a minus
sign (Unicode 002D "hyphen-minus") to "reset" a list option to the
empty list, so the new values don't just append to the existing list
of values.  That makes sense when overriding/supplementing options in
earlier unit files, but systemd::unit installs the "main" unit file,
the one that is read first, so list options *always* have the empty
list as their value when the file is read.

We here modify the unitfile.erb template file to see if it is called
from systemd::unit or systemd::unit_options, and if the former, it
raises an error if it encounters an option name starting with a minus
sign.  And of course also remove the paragraph describing that beha-
viour in the 'options' parameter documentation.

This adds a new definition, systemd::unit, for managing unit files
in /etc/systemd/system.  The content of the unit file can be given
as a hash of hashes (like in the systemd::unit_options definition),
as a string, or as a path or puppet: URL to a file to copy.

Since we use the same ERB template file for formatting the hash of
hashes into an ini-style file in both systemd::unit_options and
systemd::unit, we have renamed the template file to "unitfile.erb",
to be more neutral.  The comment at the end mentioning from where
the file is managed, now takes the Puppet definition as a parameter,
set by the definition.

This adds the semi-internal class 'systemd::vars' containing various
paths and other constants for use in the rest of the module, so we
won't need to repeat ourselves.  Currently only contains a single
variable, $etcdir, pointing to /etc/systemd/system.

The default case in the case switch for the $ensure parameter was
incorrectly using the *string* "default" instead of the keyword
``default''.  This meant that you did not get an error message if
you specified an illegal value for that parameter (unless it happened
to be exactly the string "default").

This adds the class 'systemd::daemon_reload', which can be used
to tell systemd to re-read its service configuration files.

This will contain a Puppet module for helping managing the systemd(1)
init system and systemd service configuration files.