Make the Docker image self-contained: build the binary inside the Dockerfile

Start with Dockerfile and the binary build steps in .github/workflows/docker.yml, especially the referenced workflow and Dockerfile lines. Build the Rust binary in a separate builder stage, copy it into the runtime stage, and update the workflow to run docker buildx build without separate binary artifacts. Done means a clean checkout builds the image with docker build and the workflow still supports multi-architecture publishing.

What problem does your feature solve?

The stellar/stellar-cli Docker image cannot be built from a clean checkout with docker build alone. The stellar binary is built by the GitHub Actions workflow and then copied into the image at build time, so the Dockerfile is not self-contained.

The binary build steps live in .github/workflows/docker.yml:

https://github.com/stellar/stellar-cli/blob/343069bb5e0404de643ab82e9fc2f38e056cdd08/.github/workflows/docker.yml#L36-L40

The Dockerfile then expects the pre-built binary to already be present in the build context:

https://github.com/stellar/stellar-cli/blob/343069bb5e0404de643ab82e9fc2f38e056cdd08/Dockerfile#L9-L10

This makes it difficult to test changes to the Dockerfile and the resulting image locally. To build the image a developer has to:

1. Read the GitHub workflow.
2. Replicate the binary build steps in an Ubuntu environment matching the workflow.
3. Place the resulting binary at stellar-${TARGETARCH}/stellar in the build context.
4. Run docker build.

That is fragile and error-prone, and any change to the build process has to be kept in sync across the workflow and the Dockerfile.

What would you like to see?

Move the binary build into the Dockerfile itself as a separate builder stage so the image is self-contained:

• A builder stage based on rust:latest that installs build dependencies (libudev-dev, libdbus-1-dev) and runs cargo build --package stellar-cli --release.
• A final runtime stage that uses COPY --from=builder to pull the resulting stellar binary into place.

The GitHub workflow would then just run docker buildx build (multi-arch) and push, with no separate "build binary" job and no artifact upload/download dance.

Benefits:

• Anyone can build and test the image locally with a single docker build from a clean checkout, no workflow knowledge required.
• The Dockerfile becomes the single source of truth for how the image is built.
• No drift between the workflow's build steps and the Dockerfile's expectations.