conmon: fall back to the runtime's exit status file

conmon: fall back to the runtime's exit status file

conmon learns a container's exit status by waiting for the pid it reads from
the runtime's --container-pidfile, which only works while the container is
conmon's own child. With ujail the container belongs to procd, so conmon has
nothing to wait for: it probes the pid with kill(pid, 0), finds it gone and
settles for a status of zero, as its own comment admits. podman then reports
0 for a container that exited 42, and an exec session that succeeded looks
like a failure.

Add a patch letting the runtime supply what conmon cannot observe: ujail
writes the status to an exit_status file beside the pid file, and conmon
adopts it in the one place it would otherwise guess. A runtime whose
container conmon does reap is unaffected, since no such file exists there.

020-fall-back-to-runtime-exit-status-file.patch also picks up two
fixes review caught: the fallback to a status of 0 now waits up to a
tenth of a second in 10ms steps for the runtime to finish writing the
file, since the runtime can only write it after the kernel has
already reaped the container and made the pid stop answering conmon's
probe, so either order is possible; and a status file is only trusted
if it is at least as new as the pid file, so a stale one left by an
earlier container in the same directory is ignored. Its header also
lost the `diff --git`/`index` lines and `git format-patch` version
trailer that don't survive `make package/conmon/refresh`, which is
what CI's "Dirty patches detected" check was catching on every
architecture. Verified via a scratch quilt tree against the pristine
2.2.1 source that the refreshed patch applies cleanly and stays
stable under a second refresh, and that the patched ctr_exit.c and
ctr_stdio.c both syntax-check clean against host glib.

Signed-off-by: Daniel Golle <redacted>