soroban-cli: typescript bindings and client modularity

No files or tests are named. Start by reviewing the current soroban-cli, TypeScript bindings, and JS SDK entry points for building, simulating, signing, and sending transactions, then compare their separation with the listed workflows. Done means agreeing on whether the APIs support those flows and state-modification points, or identifying the concrete modularity work still required.

This issue was originally discussed in Slack (slack thread) and started by @tomerweller. Moving some snippets of discussion captured over into GitHub issue for more async and further discussion.

@tomerweller: I wonder if there’s a modularity (or lack-thereof) issue with the current build/simulate/sign/send flow in ts-bindings. What if I want to skip simulate? For example if I want to manually fill in footprint/fees/auth? Or use a cached version of these from a similar past invocation?

@leighmcculloch: There's a break up of actions at the layer below the generated code. The SorobanClient can be used to build a tx for an invocation, to do simulation, and submit, and those three actions are independent.

At some point we talked about there being a variety of flows for the CLI such as:

1. Only simulate
2. Only submit
3. Simulate and submit
4. Simulate and maybe submit (if footprint is write, or if events written)

The same principles would apply in the JS/TS.
But it's helpful for us to have some good default behavior, which I think is (4).
It looks like the generated TS bindings have support for (1) and (4) at the moment via the responseType field.

@leighmcculloch: I think once the tx is built, the logic no longer needs to be part of the generated bindings. The specialty of the generated bindings is really focused on knowing what fn to call, and needing to turn that into a tx. And beyond that we could build all those other flows on a tx. So that all workflows operate around the build tx step. Something like:

My comment above is a little too simplified, as @chadoh has pointed out in the slack there there's other logic currently tied up in the assembled transaction like automatic backoff for sending, rebuilding and resimulating for resending. But I think across both the CLI and the TS bindings, and in general the way the JS and other clients are structured, we need to maintain some modularity so that folks can do all of the things above, and modify state between any of them.

This was originally discussed at the end of November, so if we've already moved on from here and this is out-of-date I can close it. I'm opening this issue to capture the need for us to evaluate if we have sufficient modularity, and if we provide the above different ways to interact with the network/soroban, and to dig into this further if we aren't quite there yet.

I think this issue belongs to the soroban-cli, typescript bindings, and the JS SDK.

cc @chadoh @willemneal @piyalbasu @jeesunikim @Shaptic