orchestration: use asyncFlow orch function as the target for receiveUpcall

[0xpatrickdev]

What is the Problem Being Solved?

Currently, receiveUpcall handlers, a.k.a ibc hooks, transfer tap, require API consumers to write vows and vow handlers. Developers should be able to use an asyncFlow / orchFn as the handler for receiveUpcall.

Description of the Design

• @agoric/orchestration provides a helper that:
  • sets up an Exo for the receiveUpcall transfer tap
  • allows the developers to initialize state in the above exo
  • allows a developer to provide an orchFn that will be used as the handler
  • allows developers to access their provided state in the orchFn (a la https://github.com/Agoric/agoric-sdk/pull/10065/files#r1798683748)

Security Considerations

None; should limit hazards / footguns of working with vows

Scaling Considerations

Test Plan

Upgrade Considerations

[0xpatrickdev]

Via #10065, it doesn't seem we can do {...this.state} in an exo for a generic implementation. Perhaps there's a different way to ask an exo for its keys, but i was seeing this logging inside an method:

@@@@tap this.state {}
@@@@tap Object.keys(this.state) []
@@@@tap this.state.config {
  validator: {
    chainId: 'cosmoshub-4',
    encoding: 'bech32',
    value: 'cosmosvaloper1test'
  },
  localChainAddress: {
    value: 'agoric1fakeLCAAddress',
    encoding: 'bech32',
    chainId: 'agoric-3'
  },
  remoteChainAddress: { chainId: 'cosmoshub-4', encoding: 'bech32', value: 'cosmos1test' },
  sourceChannel: 'channel-405',
  remoteDenom: 'uatom',
  localDenom: 'ibc/BA313C4A19DFBF943586C0387E6B11286F9E416B4DD27574E6909CABE0E342FA'
}

[0xpatrickdev]

See #10047, which aims for an updated example contract instead of a generic, reusable exo