Feature Request: Support Two Phases to Start Exec Process like Init

Currently, the exec-process is created by runc-exec one command.
The common container engine layer will care about the exit code of
exec-process, which required that the runc-exec's parent process
must be the subreaper.

Since pidfd_open(2) is available, we can watch the exit event
by pidfd and retrieve the exit code provided bpf sched_process_exit
tracepoint. The PID=1, like systemd, will be reaper of exec-process.
So, the common container engine is not required to be subreaper of
exec-process, like what embedshim containerd plugin does. However,
non-subreaper mode requires that exec-process starts in two phases.

1. Fork: Setup and waiting for the exec.fifo event

   • container engine opens pidfd and trace it by eBPF

2. Exec: Signal the init and start to exec

Currently, embedshim uses runc-exec wrapper command to be temporary
subreaper to sync the status, like:

[ runc-exec-ext(child, after finish runc-exec)]		            [     embedshim(parent)    ] 

	SyncExecPid		                      -->	           Read exec-process pid

                                                      <--                SyncExecPidDone
	
    SyncExecPidStatus		                      -->	         Get exec-process current status
	
					             <--	            SyncExecPidStatusDone

It is heavy mode to start exec-process for non-subreaper, so I file
this issue to request the feature for two phases to exec-process:

• runc exec-create
• runc exec-start

Looking foraward to the feedback! Thanks!

Start with the runc-exec entry point and the requested runc exec-create and exec-start commands, tracing how the current one-command flow waits on exec.fifo and reports process status. Done means exec-process can be prepared in a fork phase, then started in an exec phase, while its exit event and code remain observable through the proposed pidfd and eBPF approach.