Support Service Limits specified in Bytes

[optiz0r]

Pull Request (PR) description

Previously the ServiceLimits type restricted limits specified in bytes to contain
a multiplicative suffix. The systemd man pages ([0], [1]) specify these are optional
and a bare integer can be specified, which will be interpreted as Bytes.

This commit makes the multiplicative suffixes optional, and adds tests for two cases
to ensure non-suffixed values are accepted.

[0] https://www.freedesktop.org/software/systemd/man/systemd.exec.html
(For Limit* options)
[1] https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#
(For Memory* options)

[traylenator]

I get that values without units is permissible but maybe it's a good thing to encourage by forcing units to be specified?

[optiz0r]

The use case we have for this is the same configuration needs to be done in multiple places, and one place (pam) does not support suffixed units, and we would like to be able to use the same hiera value to drive both. The current validation prevents this, despite it being legal config. The alternative is having to duplicate config, or having some puppet function that can translate between suffixed and non-suffixed values to work around this validation being overly strict.

That said, I've just re-checked the docs for both, and pam takes kilobytes, whereas systemd takes bytes, so taking the pam value as is and shoving a K on the end would achieve the same result as trying to specify the value as an integer number of bytes multiplied by 1024.

[traylenator]

For that use case you can probably do.

pam::thing: 500
systems::thing: "%{alias(pam::thing)}b"

Or if it is in the same file with a YAML variable.

[smortex]

I don't understand the part about PAM, it seems to be something you care on your control repo and out of scope of this PR, so I will ignore it.

If we reject acceptable value we need to adjust our code and this look fire to me.