Currently, when exec-ing into a WCOW container with a stdin pipe via ctricl (or the shim via shimdiag exec) internal/cmd:Cmd.Wait() closes the underlying process and returns to internal/cmd:ExecInUvm() without waiting on or closing the go routine that copies data from the upstream stdin pipe (which is exposed to containerd) to the process's stdin (via relayIO) in the background. ExecInUvm then closes the upstream std IO pipes. (Note: this is different from exec.Cmd, which does not finish Waiting until stdin is either closed or yields an EOF on a read.)

This yields several errors, one from the relayIO function:

Message: 	Cmd IO relay complete
error: 	 	file has already been closed
file: 	 	stdin

And one from the background go routines, when they attempt to close their respective IO pipes:

Message:	failed to close Cmd stdin

With the error on hypervisor-isolated containers:

error:		close hvsock [...]: shutdown: An operation was attempted on something that is not a socket.

And on process-isolated containers:

error: 		hcs::Process::CloseStdin [...]: hcsshim: the handle has already been closed

This PR solves several issues that raise those errors.

Currently, if the exec exits without the caller first closing stdin, the IO relay for stdin is guaranteed to raise the file has already been closed error, which is raised by winio when attempting to read from a closed pipe. internal/cmd:relayIO was modified to ignore file closed errors from the io.Copy on stdin, but not from stdout and stderr, since those closing are likely anomalous.
Since there is no guarantee as the ordering between cmd.Wait calling process.Close and the relayIO go routines calling process.CloseStdin/out/err, the close IO operations now ignore file has already been closed errors.
hcs.ErrAlreadyClosed from process.Close are now also ignored, as cmd.Wait() may call it twice.

internal/gcs:Process was updated to match internal/hcs:Process and internal/jobcontainers:Process:

1. .CloseStdin/out/err functions return hcs.ErrAlreadyClosed if the process was already closed;
2. .CloseStdin first calls CloseWrite to send an EOF, and then closes the IO channel; and
3. .Close zeros out its gc connection to prevent future accidental uses, and protects gc with a RWLock so closing does not occur while other operations that require the guest connection are executing.

For internal/hcs:Process, if process.CloseStdin is called after the process exits but before it is closed, it sends an HcsModifyProcess request, which errors:

error: 	The process has already exited.
name: 	HcsModifyProcess
settings: 
{
	""Operation"": 	""CloseHandle""
	""CloseHandle"": 	{""Handle"":""StdIn""}
}

Now it checks if the process exited before sending the close handle request.
Additionally, it retuned hcs.ErrAlreadyClosed if the process.CloseStdin was called on a closed process, but did not do the same for CloseStdout and CloseStderr. The latter two were updated to match CloseStdin and jobcontainers:Process.

Finally, a flag was added to internal/cmd:Cmd to close the upstream Stdin IO channel after the process exits but before Cmd.Wait() waits on the IO operations. This allows callers to close the upstream stdin and guarantee that the stdin io.Copy operations end safely and properly after the process exits.

Note: it is impossible to guarantee interrupting the io.Copy operation without closing the upstream pipe, as it can block indefinitely on the syscall to read from the upstream stdin pipe. Therefore, only closing or sending an EOF (via .CloseWrite(), which is not available on the default, non-message based winio Pipes) will end the go routine copying data from that pipe.

Tests were updated to account for new functionality.

Signed-off-by: Hamza El-Saawy [email protected]