orchestration transfer() vow should not resolve until the remote chain confirms

[turadg]

What is the Problem Being Solved?

transfer method in local-orchestration-account.js returns a vow that returns once the message is put in the outbox. The transfer isn't really complete until the remote chain confirms. Moreover the transfer may fail and in that case the vow should reject.

Same goes for cosmos-orchestration-account.js but that's "Not yet implemented". I wrote the PR title generically as a product requirement.

Description of the Design

Prior art: https://gist.github.com/michaelfig/280acc7d0bb1eb10bf7570929305bb80

Monitor transfers accepts a single “app” / “tap” at a time. If we use it in a platform-level service that watches outgoing transfers and resolves promises, we still need to support developers registering their own handlers. We could use the one slot with a generic handler that calls out to other handlers.

Security Considerations

Scaling Considerations

Test Plan

Upgrade Considerations

[dckc]

transfer() uses executeTx; docs for executeTx say it waits for an ack. Is that just not right?

agoric-sdk/packages/vats/src/localchain.js

Lines 153 to 166 in 369fa7c

	/**
	* Execute a batch of messages in order as a single atomic transaction
	* and return the responses. If any of the messages fails, the entire
	* batch will be rolled back. Use `typedJson()` on the arguments to get
	* typed return values.
	*
	* @template {TypedJson[]} MT messages tuple (use const with multiple
	* elements or it will be a mixed array)
	* @param {MT} messages
	* @returns {PromiseVowOfTupleMappedToGenerics<{
	* [K in keyof MT]: JsonSafe<ResponseTo<MT[K]>>;
	* }>}
	*/
	async executeTx(messages) {

[michaelfig]

transfer() uses executeTx; docs for executeTx say it waits for an ack. Is that just not right?

A "response" (ResponseTo<MsgTransfer>) above is promptly returned indicating the local transaction has completed in the same block that the cosmos layer received it (without any cross-chain interaction). For MsgTransfer, that return consists of just a sequence number to track the transfer which has been submitted to the IBC layer, and is waiting to be relayed to another chain. An IBC "ack" is multiblock, from a relayer sending an inbound IBC acknowledgement or timeout packet back in a transaction to the initiating chain, which the VM can correlate via the matching sequence number as the reply to the outbound transfer packet.

---

A brief segue: here's the Monsterpiece Theatre I acted out for @turadg and @0xpatrickdev when explaining these separate layers:

Alice writes a note to Bob, stamps it with a sequence number, and puts the note in her outbox

Without #9820: Alice jumps the gun and says: "Message sent! Full speed ahead!" Curtains.

With #9820: Ray collects the notes from Alice's outbox, delivers one to Bob's inbox.

Bob reads Alice's note, and performs the requested work, however long it may take.

Bob puts a reply note to Alice in his outbox, stamped with Alice's sequence number.

Ray collects the notes from Bob's outbox, delivers one to Alice's inbox.

Alice reads Bob's note, and decides between:

Alice says: "Message confirmed! Full speed ahead!"
-or-
Alice says: "Abort! Abort!"

Curtains.