[EPIC] generic tx building and signing

[janewang]

Breaking down this epic into chunks

---

### Critical for asset issuers to support advanced signing
- [x] Modifying existing commands so they can build a tx only: #1265

### Break up of currently unified behaviors to support composability
- [x] Add a `soroban tx simulate` command. That simulates any given tx and returns the modified/assembled tx that has fees, footprint, etc.
- [ ] Add a `soroban tx send` command. Submits to the network, does nothing else.
- [ ] Add a `soroban tx sign` command.That supports all existing and future signing capabilities just takes a tx base64 as input and returns it as output. https://github.com/stellar/stellar-cli/issues/1490

### Convenience commands for common tx XDR ops
- [x] Add a `soroban tx decode` command. This could be a lightweight wrapper around the XDR>JSON decoder command, `soroban lab xdr decode --type TransactionEnvelope`.
- [x] Add a `soroban tx encode` command. This could be a lightweight wrapper around the JSON>XDR encoder command, `soroban lab xdr encode --type TransactionEnvelope`.

### Bigger and more involved features
- [ ] Live edit experience in a `soroban tx edit` command. [Design doc](https://docs.google.com/document/d/1MHjQ-R6Dh_Ykhq5VcOT-d1-z5yoNrPC5RjNA0MEmEno/edit#heading=h.dn3a9fxqk3pq) Opened separate issue here: https://github.com/stellar/soroban-cli/issues/1290

[willemneal]

Linked PR #1263

[leighmcculloch]

I think we need to break up this issue into a set of sub-issues and prioritise them, because some of the work is more urgent, and we get big wins from some of the smaller easier parts of this work.

I suggest we break this up into the following features and prioritise in this order:

---

Critical for asset issuers to be able to use the CLI, since they have unique advanced signing setups:

• [ ] Modifying existing commands so they can build a tx only: #1265

• [ ] Add a soroban tx simulate command.

  That simulates any given tx and returns the modified/assembled tx that has fees, footprint, etc.

---

Small, doesn't require a ton of design or new complex work:

• [ ] Add a soroban tx send command.

  Submits to the network, does nothing else.

• [ ] Add a soroban tx sign command.

  That supports all existing and future signing capabilities just takes a tx base64 as input and returns it as output.

• [ ] Add a soroban tx decode command.

  This could be a lightweight wrapper around the XDR>JSON decoder command, soroban lab xdr decode --type TransactionEnvelope.

• [ ] Add a soroban tx encode command.

  This could be a lightweight wrapper around the JSON>XDR encoder command, soroban lab xdr encode --type TransactionEnvelope.

• [ ] ~Initialise common tx templates.~ (Edit: Not needed because that's what all the other commands in the CLI are.)

---

A lot of work, big pay off if done right, hard to get right, time consuming:

• -like live editing experience, in a soroban tx edit command.

---

Is this missing anything?

[leighmcculloch]

@willemneal The tx sign command will need to be able to do signatures of txs or soroban auths, is that what you're working towards at the moment, just focusing on just one or the other? We can track both separately if needed.

[willemneal]

Would be be thinking tx sign-auth? Or do we just let it figure out what needs to be signed?

[leighmcculloch]

A user calling tx sign should have already inspected the tx to identify if they want to sign it, and there's little point in most transactions only signing some things, so I think the tx sign command should sign everything (tx and auths) that it can for the signer specified.

I think it's important that the signer signing is explicitly specified, such as with a --signer <alias|account>, so that you can't accidentally sign something with a second key you have loaded that you don't intend to.

@janewang @fnando @chadoh thoughts?