Implement API forwarding for podman machine on Windows

[n1hility]

Implements API forwarding for podman machine on Windows, providing out of the box Docker API client access (the windows variant of #11462, and portion of #11422)

This support builds on the standalone ssh proxying facility for windows (win-sshproxy.exe) that was contributed to gvproxy (containers/gvisor-tap-vsock#88). A standalone approach is necessary since:

• Podman doesn't implement daemons
• There is no vsock layer involved since WSL handles networking transparently

It does however share the same implementation with the ssh facility that was added to gvproxy.

This approach prefers to bind to the default pipe address expected by Docker API clients, if it is available:
\.\pipe\docker_engine

However, if a user is running a process which has it bound (e.g. they are running something like Docker Desktop, or using multiple instances of podman machine), then it will fall back to a machine namespaces pipe name that should be unique.

Helpful messages are provided in both scenarios:

1. Default global pipe is available

PS C:\Users\User> podman machine start
Starting machine "podman-machine-default"
API forwarding listening on: npipe:////./pipe/docker_engine

Docker API clients default to this address. You do not need to set DOCKER_HOST.
Machine "podman-machine-default" started successfully

2. Default global pipe is taken by another process ATM

PS C:\Users\User> podman machine start
Starting machine "podman-machine-default"
API forwarding listening on: npipe:////./pipe/podman-machine-default

Another process was listening on the default Docker API pipe address.
You can still connect Docker API clients by setting DOCKER HOST using the
following powershell command in your terminal session:

        $Env:DOCKER_HOST = 'npipe:////./pipe/podman-machine-default'

Or in a classic CMD prompt:

        set DOCKER_HOST = 'npipe:////./pipe/podman-machine-default'

Alternatively terminate the other process and restart podman machine.
Machine "podman-machine-default" started successfully

Example Docker API Client Output

PS C:\Users\User\docker\docker> .\docker.exe version
Client:
 Version:           20.10.12
 API version:       1.40
 Go version:        go1.16.12
 Git commit:        e91ed57
 Built:             Mon Dec 13 11:44:07 2021
 OS/Arch:           windows/amd64
 Context:           default
 Experimental:      true

Server: linux/amd64/fedora-35
 Podman Engine:
  Version:          3.4.4
  APIVersion:       3.4.4
  Arch:             amd64
  BuildTime:        2021-12-08T15:45:07-06:00
  Experimental:     false
  GitCommit:
  GoVersion:        go1.16.8
  KernelVersion:    5.10.60.1-microsoft-standard-WSL2
  MinAPIVersion:    3.1.0
  Os:               linux

win-sshproxy.exe Details

See specific implementation details in containers/gvisor-tap-vsock#88

The ssh proxy is implemented as a background service, so there is no attached console. Logging goes to the windows event log, which can be viewed using either the windows event viewer or powershell commands like the following:

TimeCreated                      Id LevelDisplayName Message
-----------                      -- ---------------- -------
1/18/2022 4:44:27 PM           1000 Information      [info ] podman-machine-default: Listening on: \\.\pipe\docker_engine...
1/18/2022 4:44:28 PM           1000 Information      [info ] podman-machine-default: Socket forward established: //./pipe/docker_engine to /run/podman/podman.sock

Important Build Process Note

A possible controversial change is the new Makefile target which does a git checkout of a specific SHA of containers/gvisor-tap-vsock to build the helper executable. This action is only performed when building the Windows Installer (podman.msi task) which needs to include the executable with podman.exe (an external dependency would be a major usability hurdle)

The other approach I had first attempted was to just add a dependency on single package in gvisor-tap and use a thin cmd/ impl. However the problem with this approach is the transitive deps conflict and would require alignment between the two projects. This seems like a no-go since the only reason for the dependency is just the single command.

Another alternative approach would be to break out a separate project that both gvisor-tap-vsock and podman could depend on, but this seems like an unnecessary overhead for something with small scope that is likely to have minimal changes.

[NO NEW TESTS NEEDED] , waiting on ephermal azure capabilities in Cirrus CI

[rhatdan]

/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: n1hility, rhatdan

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [rhatdan]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[rhatdan]

@containers/podman-maintainers PTAL

[mheon]

LGTM

[n1hility]

@jwhonce FYI pushed a commit to switch those outputs to stderr

[jwhonce]

/lgtm