Since NixOS/nixpkgs@340dd80, meson no
longer propagates the Python dependency, so for our minimal
configurations we still need to add Python to the list of
nativeBuildInputs.

I haven't actually noticed this so far because I actually forgot to bump
the Hydra jobset to 19.03 for quite a while and soon I'll probably
forget to bump it to 19.09, let's see... ;-)

Signed-off-by: aszlig <aszlig@nix.build>

The rule file options were defined earlier than the rule specification
options (via the -r command line flag) and when designing the rule
specification format, I tried to keep options as short as possible.

Unfortunately, this introduced inconsistencies between the naming of
options in both rule formats and the major offender is "socketPath" in
the rule file, where it is just "path" via the command line argument.

So when renaming, I didn't remove the old option but rather print a
deprecation warning instead to make sure we don't immediately break
things for users.

Signed-off-by: aszlig <aszlig@nix.build>

In the previous commit, we renamed the socketPath option to reduce
differences between rule specifications via command line and options in
the rule file.

Another option is "socketActivation", which is just called "systemd" in
the CLI specification.

The name/semantics of this option however might still be subject to
change, depending on how we are going to rename the fdName option,
because setting eg. fdName to "foo" is equivalent to "systemd=foo" in
the CLI specification.

One example where we'd need to touch the "systemd" option again is if
we'll end up with nested options like this:

  systemd:
    enable: true
    fdName: foo

Signed-off-by: aszlig <aszlig@nix.build>

Unify CLI rule specification options with rule file options

This reverts commit 31fa1ab, reversing
changes made to 54d96bb.

The changes here were NOT intended to be merged into master, because
they're for the next minor version and there are still open questions as
detailed in the pull request.

Furthermore, I intended to merge this alongside the next release so the
README stays consistent with its implementation.

For example something like accept(fd, NULL, NULL) is perfectly valid and
it's actually the most obvious case when writing a very simple socket
client or server in C and you're not interested in the peer address.

It turns out that actually very few services in the wild are doing this
and they usually always pass the buffers for the peer address.

However, this is not the case for something like Boost.Asio and we will
segfault to death due to a null pointer dereference.

The reason why we didn't catch this earlier is that we're using Python
to test our implementation, which *always* passes those buffers to
accept (or accept4 to be more exact).

Now the problem is that it's not very easy to use accept(fd, NULL, NULL)
in Python, so I decided to add a small helper in C++ to our tests for
that. This messes up our test hierarchy a little bit, but we need to
clean up this mess someday anyway, so let's load another trash bag on
it... X-/

Nevertheless, the most important thing here is that we now also have a
test that covers this case, so embarrassing bugs like this one won't
happen again.

Signed-off-by: aszlig <aszlig@nix.build>

Tests are all still passing and this is an important hotfix release, so
even thout it only contains one little fix I still consider this
necessary to release it as soon as possible.

Signed-off-by: aszlig <aszlig@nix.build>