config: switch PidsLimit to *int64

[cyphar]

Previously we would treat a value of "0" as meaning "no-op", which lead
to quite a bit of confusion. The runtime-spec has been updated to make
the "pids.limit" value a pointer, and explicitly state that:

• Values >= 0 should be treated as normal values; and
• -1 indicates "max".

In practice this means we should switch PidsLimit to an *int64. Luckily,
this is actually backwards-compatible with our previous JSON -- an old
value of "0" would be omitted from the output, which will now be parsed
as "nil". The handling by our cgroup code would be identical but the
latter now correctly reflects the guidance by the runtime-spec.

Ref: opencontainers/runc#4014
Ref: opencontainers/runtime-spec#1279
Signed-off-by: Aleksa Sarai cyphar@cyphar.com

We now remap <0 to -1 and correctly handle some other annoying cases (TasksMax=0).

[cyphar]

@kolyshkin This now passes in runc's CI, but since systemd doesn't support TasksMax=0 we need to remap 0 to 1 -- should we just do the same thing in the fs driver?

[kolyshkin]

@kolyshkin This now passes in runc's CI, but since systemd doesn't support TasksMax=0 we need to remap 0 to 1 -- should we just do the same thing in the fs driver?

I guess so, yes. Otherwise setting it to 0 will result in systemd driver writing 1 when fs driver writing 0, and after systemctl daemon-reload (or some such) systemd will write 1 again. Who knows what kernel might do in this case, so it's better not to oscillate between 1 and 0.

[cyphar]

Okay, let's go with that then. I will add an implementors note to the runtime-spec...

[cyphar]

Done!

[kolyshkin]

LGTM