Expose stdin/stdout/stderr streams for Containers and Executables

[karolz-ms]

Feature description

Users may desire to interact directly with resources. E.g. Aspire dashboard might want to have a terminal emulator that one could attach to a container-based-, or process-based resource and interact directly with it. Or an MCP server with stdio interface might be part of Aspire workload and one would need to access its stdio streams to use it.

Design outline and constraints

1. Both Executable and Container resource get a flag that enables "attaching to stdio" (stdin + stdout + stderr). When this flag is present, we capture and memorize standard file descriptors for a given resource as it is started.

   Consider if we could enable attaching to stdio for all Executables and Containers

2. Executable and Container API objects get a stdio subresource. When that subresource is queried, we create and return paths to 3 Unix domain sockets that are attached to relevant resource file descriptors. We also start a proxy that will push data between these sockets and resource file descriptors.

   These paths could also be simply status properties of Executable and Container objects.

3. Standard output and standard error streams are captured and stored in (raw) temporary files from the moment a resource (with AttachToStdio == true) is started. They are also forwarded to the log writer so the existing log streams continue to work for AttachToStdio == true resources.
4. When a new client connects to stdout or stderr socket, the existing content is replayed to it.
5. If more than one client connects to stdin socket, bad things might happen 😄

Additional notes

Related to https://github.com/microsoft/usvc/issues/241

@sebastienros has created a proof-of-concept https://github.com/microsoft/usvc-apiserver/tree/sebros/stdin The details are different from the design outline above, but it illustrates the potential.

[karolz-ms]

The above will only work for the standard (process) execution mode. We need to enhance the IDE protocol explicitly to enable this for the IDE execution mode (and not all IDE's/program types will support it).

[karolz-ms]

Design update from discussion with @mitchdenny @sebastienros and @danegsta

Executables and Containers will have I/O 3 modes, requested via spec property:

1. Regular mode (only console logs available, no stdin access) -- default, the current behavior.

2. Simple I/O mode -- DCP creates a Unix domain socket for I/O. Incoming bytes are written to stdin; combined output from stdout and stderr is written back to the socket. No support for terminal resizing.

3. Full terminal mode -- when launching Executable or Container, DCP allocates a pseudo-terminal for it (pseudo-console on Windows). The object specification contains a path to Unix domain socket that will serve as the terminal connection for the Executable/Container. Terminal resizing is supported via proprietary enhancement to the input data stream.

   For example, we could decide that incoming characters starting with 0x10 0x1b (LF ESC) and ending with LF are a command that DCP needs to handle (if the body of the command recognized). And if there is ever a need to send data that has LF ESC sequence, the ESC character needs to be doubled (DCP will automatically remove the second ESC character).

[karolz-ms]

Promising, cross-platform library for handling pseudo-terminals in Go: https://github.com/aymanbagabas/go-pty?tab=readme-ov-file