Show the native contract asset address in output

[leighmcculloch]

What

Add stellar-strkey CLI tool to the Docker image build pipeline. Display the native asset contract address in the startup output using the network ID and stellar-xdr/stellar-strkey tools.

Why

A first step towards automatically deploying the stellar asset contract for the native asset. It is also helpful to see the native asset contract address in the output along with the network id and network information, but the main purpose is to get that information available to the start script so that in a future change the start script can deploy that contract and knows what the address is for prebuilding the tx without simulation.

For #555

[Copilot]

Pull request overview

This PR adds the stellar-strkey CLI tool to the Docker image build pipeline and displays the native asset contract address in the startup output. This is a preparatory step toward automatically deploying the Stellar Asset Contract for the native asset in future changes.

Key Changes:

• Adds stellar-strkey as a new dependency across all image configurations
• Implements a bash function to calculate the native asset contract address using the network ID
• Displays the calculated contract address in the startup output alongside other network information

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
start	Adds calculate_native_asset_contract_address() function to compute the native asset contract address, displays strkey version info, and outputs the calculated contract address during startup
images.json	Adds stellar-strkey dependency (v0.0.14 for stable releases, main for development) to all five image configurations
Makefile	Extracts STRKEY_REPO and STRKEY_SHA variables from image configuration and passes them as build arguments
Dockerfile	Adds stellar-strkey-builder and stellar-strkey-stage build stages, copies the stellar-strkey binary to the final quickstart image
.github/workflows/internal-build.yml	Adds artifact download step for the strkey image to match the pattern used for other dependencies

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[leighmcculloch]

After this change is merged a next feature I'd like to do is submit a transaction deploying the native asset contract automatically for local networks (#555). It's possible to do that in the same way as this, using jq, and other linux command line tools, however this is getting more and more brittle.

Instead of merging this change I am contemplating creating a small Rust application, a CLI, that does the same and lives here in the Quickstart image, and would contain any logic that needed to existing within the image but was not trivial enough to live in a script. It would have some overlap with the stellar-cli, but the intent is to stay low level, minimal, and to have dependencies only on very low level components that are released super early as part of stellar-core, such as the stellar-xdr crate and the stellar-strkey crate.

The small Rust app would be much less brittle.

An alternative would be to ship the stellar-cli with quickstart. I am hesitant to do that though because it is so much further downstream. Ideally quickstart can quickly adopt a just-released stellar-core, or even an unreleased stellar-core using new XDR definitions.