unify termination algorithm for v1/v2
- for each snap cgroup:
  - while cgroup.procs is not empty:
    - SIGKILL each pid in cgroup.procs
- for v1 only, also kill pids found in freezer cgroup created by snap-confine
  - this is relevant for systemd v237 (used in ubuntu 18.04) for non-root users where the transient scope cgroups are not created

This logic drops the freeze/kill/thaw approach with all the weird v1/v2/kernel backward compatibility.

Signed-off-by: Zeyad Gouda <[email protected]>

Signed-off-by: Zeyad Gouda <[email protected]>

This test variant stress-tests the new algorithm where snapd could be racing
after a fork bomb without doing freezing first by continuously killing pids
that show up until all pids are drained from cgroup.

Signed-off-by: Zeyad Gouda <[email protected]>

Signed-off-by: Zeyad Gouda <[email protected]>

Signed-off-by: Zeyad Gouda <[email protected]>

Signed-off-by: Zeyad Gouda <[email protected]>

Signed-off-by: Zeyad Gouda <[email protected]>

…nCgroup

Signed-off-by: Zeyad Gouda <[email protected]>

…esses for v1

Signed-off-by: Zeyad Gouda <[email protected]>

This syncs snap-confine and this task to make sure they are not racing
on two important resources:
   - Remove inhibition lock (which snap-confine exits when observing)
   - V1 freezer cgroup (which snap-confine creates and joins)

This is needed to address an issue in systemd v237 (used by Ubuntu 18.04) for
non-root users where no tracking transient scope cgroups are created except
the freezer cgroup which is created in snap-confine after the inhibition lock
is release by "snap run".

Effectively the sequence below is followed:
- kill-snap-apps task holds snap lock
- kill-snap-apps holds remove inhibition lock
- snap-confine holds snap lock
- snap-confine exits if remove inhibition lock exists
- snap-confine creates/joins freezer

Signed-off-by: Zeyad Gouda <[email protected]>

…up v1

When sending SIGKILL signals to snap pids in a frozen v1 cgroup a thaw must
be done for those signals to take effect.

Signed-off-by: Zeyad Gouda <[email protected]>

…roying test machine

The fork-bomb test variant was destroying test machines especially those with
older systemd versions where DefaultTaskMax was unlimited.

This runs the fork-bomb test variant under a separate user whose TasksMax is
limited.

Signed-off-by: Zeyad Gouda <[email protected]>

…ariant

Amazon Linux 2 does not support systemd --user needed by the
fork-bomb variant of the test.

Signed-off-by: Zeyad Gouda <[email protected]>

Signed-off-by: Zeyad Gouda <[email protected]>

Signed-off-by: Zeyad Gouda <[email protected]>