fixes #9719

alternative to #9775 without extra locks/goroutines/etc (ty for the idea @corhere!).

The Problem

TLDR: #9719

Long form: Communication is hard. In 5cd6210, we reworked the v2 runc shim event handling to reduce lock contention, since before, in order to preserve exit event order, we were just putting big locks around s.Create and s.processExits, which broke down under load (see #8557).

In reality, the difficult part of preserving exit event order is "early exits" – we never want a TaskExit event to be emitted for a task before it's TaskStarted or TaskExecStarted, but if a process exits very quickly after start, it's incredibly likely that we will receive an exit event from runc and emit it before we've had the time to emit the start event for the same task. To deal with that without incurring such a performance hit as we did before, we started keeping track of "running" processes (processes for which we've emitted a start event and that have not yet exited), which let us change our exit processing logic – if we receive an exit event for a PID which we're not tracking in the running processes map, it's likely due to an early exit and we can handle it properly – in this case, having s.Start calls subscribe to exits, so that when they are about to emit a TaskStart event, they can check if we've received an exit event in the meantime and handle it appropriately.

This worked great, but as we found in #9719, the extra processing that we introduced for exec exits handling made it so that in certain circumstances, even though we always receive an exit event for Execs before we receive the Init process's (this is relevant, and the causes for this are discussed in #9719 (comment)), we end up emitting the Init's exit first (since we're not holding off on processing that before we emit a Start event) and only emitting the exec exit afterwards, which causes issues (and does not represent reality).

The Fix

Credits to @corhere who came up with this approach to ensuring exit ordering – more info in #9775 (comment).

The fix boils down to:

• Add a field PendingExecCounter to containerProcess which we use to keep track of how many execs we're currently processing (i.e. for which we have called s.preStart() but have not yet called the returned handleStarted() closure).
• In s.processExits(), if a process has pending execs, we skip processing the exit.
• In the returned handleStarted() closure, if we're processing an exec and this exec is the last pending exec for an init process, check whether the init process has exited in the meantime, and if so process it's exit (after processing the relevant exec's exit).