Add a small Rust CLI tool to the quickstart image for non-trivial startup logic

[leighmcculloch]

What problem does your feature solve?

The quickstart image startup scripts use shell tools like jq, stellar-xdr, and stellar-strkey to perform tasks such as computing the native asset contract address and (in the future) deploying the native asset contract for local networks (#555). As more logic is added to these scripts, they become increasingly brittle and hard to maintain.

Context: #841 (comment)

What would you like to see?

A small Rust CLI application that lives in the quickstart image and handles any logic that is not trivial enough to live in a shell script. It would:

• Stay low level and minimal
• Depend only on very low level components released early as part of stellar-core (e.g. stellar-xdr crate, stellar-strkey crate)
• Compute the native asset contract address given a network ID
• Eventually submit a transaction to deploy the native asset contract for local networks (Automatically setup native token on quickstart local networks #555)
• Replace the current config setup that is very brittle

The intent is for this tool to be easy to update quickly when a new stellar-core is released, or even when working with an unreleased stellar-core using new XDR definitions.

What alternatives are there?

• Continue using shell scripts: Combine jq, stellar-xdr, stellar-strkey, and other CLI tools in bash. This works but becomes brittle as more complex logic is added.
• Ship stellar-cli with quickstart: This would provide the needed functionality but stellar-cli is much further downstream, making it harder for quickstart to quickly adopt a just-released or unreleased stellar-core.

[janewang]

I'm fully onboard that Quickstart needs a CLI rather than a number of brittle scripts that accumulate more logic over time. My question is whether it makes sense to introduce a separate CLI just specifically for Quickstart, given that some of the required functionality already exists in the current Stellar CLI. Creating a second CLI would increase long term maintenance for the DevX team and as we build more functionalities into the second CLI, it could potentially fragment the developer experience.

The intent is for this tool to be easy to update quickly when a new stellar-core is released, or even when working with an unreleased stellar-core using new XDR definitions.

The Stellar CLI will eventually need to support new XDR definitions regardless during release cycles, so this makes me wonder if we are creating a double of the work. All that is to say we should consider whether extending the Stellar CLI might be a more sustainable path.

If we look at ecosystems like Foundry Anvil or Solana CLI (with solana-test-validator), local node management lives within the same CLI. And I've always viewed node management as something that naturally belongs in the CLI surface area, even if it’s not the primary function and is a nice-to-have, because it creates a more cohesive developer workflow. See our roadmap for the CLI https://docs.google.com/document/d/1MqErTcY0Ar2Oh-Vz0-AUME8tmdHNyyfV_Hb1RZ47RjQ/edit?usp=sharing

[leighmcculloch]

The CLI proposed here is a utility script, not a product. The stellar-cli is too far down the stack for quickstart. This utility has to be available after core is updated, before any other tools are updated, which is why I suggest the utility depend only on stellar-xdr and stellar-strkey because those two libraries are dependencies of core and so are always updated.

We do use an embedder architecture for the stellar-cli and so functionality that ends up in this utility could be surfaced in the stellar-cli by embedded it. We do this with stellar-xdr-cli and stellar-strkey-cli, both of which are embedded into the stellar-cli under the commands stellar xdr and stellar strkey. I'm not sure it would make sense to do that in this case, but it's an option if we wanted to resurface all or some of the subcommands.