ls: improve handling of invalid builders/context, clarify relation with context

Related (see further down):

• https://github.com/docker/cli/issues/1955
• https://github.com/docker/cli/pull/3847
• https://github.com/docker/cli/pull/3878
• https://github.com/docker/cli/pull/3886
• https://github.com/docker/cli/pull/3791

⚠️ Disclaimer: I just ran into this issue on buildx v0.9.1 (Docker Desktop 4.16.1), but have not yet verified the behavior on v0.10.0;

The issue: an invalid builder (context)

When running docker buildx ls, I noticed an error message:

docker buildx ls
NAME/NODE       DRIVER/ENDPOINT STATUS  BUILDKIT                         PLATFORMS
default *       docker
  default       default         running 22.06.0-beta.0-913-g6be7129598.m linux/arm64, linux/amd64, linux/amd64/v2, linux/riscv64, linux/ppc64le, linux/s390x, linux/mips64le, linux/mips64
desktop-linux   docker
  desktop-linux desktop-linux   running 22.06.0-beta.0-913-g6be7129598.m linux/arm64, linux/amd64, linux/amd64/v2, linux/riscv64, linux/ppc64le, linux/s390x, linux/mips64le, linux/mips64
foo                             error

Cannot load builder foo: Unix socket path "/var/folders/6f/tz5jf4nn1_n5jb0ctrrw5p2w0000gn/T/TestBuildWithBuildercustom_context67217891/001/docker.sock" is too long

Apparently I have created a custom builder for testing, and that builder could not be used (path too long), so my (logical) approach was to "just remove the builder";

docker buildx rm foo
ERROR: Unix socket path "/var/folders/6f/tz5jf4nn1_n5jb0ctrrw5p2w0000gn/T/TestBuildWithBuildercustom_context67217891/001/docker.sock" is too long

That failed, and the builder is still there;

docker buildx ls
NAME/NODE       DRIVER/ENDPOINT STATUS  BUILDKIT                         PLATFORMS
default *       docker
  default       default         running 22.06.0-beta.0-913-g6be7129598.m linux/arm64, linux/amd64, linux/amd64/v2, linux/riscv64, linux/ppc64le, linux/s390x, linux/mips64le, linux/mips64
desktop-linux   docker
  desktop-linux desktop-linux   running 22.06.0-beta.0-913-g6be7129598.m linux/arm64, linux/amd64, linux/amd64/v2, linux/riscv64, linux/ppc64le, linux/s390x, linux/mips64le, linux/mips64
foo                             error

Cannot load builder foo: Unix socket path "/var/folders/6f/tz5jf4nn1_n5jb0ctrrw5p2w0000gn/T/TestBuildWithBuildercustom_context67217891/001/docker.sock" is too long

Relation with "context"

So, I guess the issue here is because docker buildx ls doesn't actually list builders, but lists contexts (and checks each context to see if there's a builder?). This is confusing.

There is indeed a context named foo, and that has a Docker Endpoint with a socket path that's too long (this may be something we should validate when creating the context);

docker context ls
NAME                TYPE                DESCRIPTION                               DOCKER ENDPOINT                                                                                                      KUBERNETES ENDPOINT   ORCHESTRATOR
default *           moby                Current DOCKER_HOST based configuration   unix:///var/run/docker.sock                                                                                                                swarm
desktop-linux       moby                                                          unix:///Users/thajeztah/.docker/run/docker.sock
foo                 moby                                                          unix:///var/folders/6f/tz5jf4nn1_n5jb0ctrrw5p2w0000gn/T/TestBuildWithBuildercustom_context67217891/001/docker.sock

Removing the context worked:

docker context rm foo
foo

And resolved the issue:

docker buildx ls
NAME/NODE       DRIVER/ENDPOINT STATUS  BUILDKIT                         PLATFORMS
default *       docker
  default       default         running 22.06.0-beta.0-913-g6be7129598.m linux/arm64, linux/amd64, linux/amd64/v2, linux/riscv64, linux/ppc64le, linux/s390x, linux/mips64le, linux/mips64
desktop-linux   docker

Start by reproducing the invalid socket-path case with docker buildx ls, docker buildx rm foo, and docker context rm foo, then read the builder and context handling paths involved in those commands. Compare the behavior with the linked issue and pull requests. Done means invalid builders or contexts are handled consistently, removable when broken, and the relationship between builders and contexts is clear to users.