bug: Show a clear warning when Docker, the Compose plugin or the Docker daemon is not available #5

Blocker: yes. Fix this before the server-monitoring work starts.

Defect

Test conditions:

1. The docker binary is not installed.
2. The docker binary is installed, but the Compose plugin is not installed.
3. The Docker daemon is stopped.

Commands in the test: start, stop, restart, wp, exec, logs, base start, base stop and status.

Results:

• No command panics.
• Users see raw Go errors, for example exec: "docker": executable file not found in $PATH. Most of these errors also have incorrect text and exit code 0 (refer to bug: Commands exit with code 0 when they fail, and show incorrect error text #2).
• fly status shows "Docker is not installed" when only the daemon is stopped.
• fly status shows "Docker is running" when the Compose plugin is not installed. It does not examine Compose.
• fly base stop shows "Base services stopped successfully" when Docker is not installed.

Cost

• Docker stops frequently on servers. Each time, users see raw or incorrect messages.
• fly status gives incorrect information about the problem. Thus, an operator can do the wrong repair.
• The server-monitoring capability must know the Docker state, and it must not fail when Docker is not available. At this time, no code finds the Docker state.

Benefit of the fix

• Users see one clear warning. The warning tells which part is not available.
• fly status shows the correct state of each part.
• The probe becomes the online/offline check of the Docker capability. Thus, the capability refactor can use this work without change.

Fix

1. Add a probe in internal/docker. The probe gives three different states:
   • The binary is installed: exec.LookPath("docker").
   • The Compose plugin is installed: docker compose version.
   • The daemon answers: docker info, with a timeout.
2. Before each Docker command, run the probe. If a part is not available, show one warning line that names the part.
3. In status, show each of the three states on a different line.

Decision necessary

Which exit code must a Docker command use when Docker is not available?

Proposal:

• Action commands exit with a special code that is not 0, for example 69 (EX_UNAVAILABLE). Then, scripts can tell the difference between "Docker is not available" and "the command failed".
• status shows warnings and exits with code 0.

Completion checks

• Each of the three test conditions gives one clear warning. No raw exec: error shows.
• status shows the three states separately.
• Tests use a fake docker script.