Report bridge inbound result to cosmic-swingset

[mhofman]

What is the Problem Being Solved?

Currently a bridge inbound (cosmos messages delivered into swingset) is an operation that does not return a result. From the cosmic-swingset side, the message is queued and forgot about. The bridge is a multiplexed channel, and handlers for each channel can actually return a promise for the result, but it's currently dropped to the floor by the bridge implementation.

For multiple reasons, we would like for the result of the bridge handlers to be reported back to cosmic swingset, or if no handler is registered, and error to be reported. In particular:

• To be able to provide a generic result event mechanism for swingset transactions: #7148
• To be able to assert that a core proposal (core eval part of an upgrade, or bootstrap in #8440) has succeeded, so that when the chain starts again, it's guaranteed to be in a consistent state. Support for #8219

Description of the Design

Like in #6741, add a special channel used to communicate results between the bridge vat and cosmic swingset. To avoid allocating and managing a reference ID, we could use the whole action context added in #7102.

The complication come in the durability of result pipeline. The bridge vat can use a durable watcher, but that's not resilient to the handler's vat getting upgraded. Alternatively, the bridge vat could pass a promise watcher object along with the reference, but that requires an upgrade of the handler vats to start using.

Security Considerations

None

Scaling Considerations

None

Test Plan

TBD

Upgrade Considerations

This requires an upgrade to the bridge vat itself, which would likely be performed as one of the core proposals, and must be ordered first through #8370. If we enforce that core proposals must succeed, this specific one must report a result somehow. @warner suggested that buildRootObject of the upgraded bridge vat could generate and "upgrade" bridge result as last step, and that the check for successful core eval execution could be satisfied by such a special message being received during execution. Since these would run in the same block, we can use a memory only flag.

[mhofman]

The complication come in the durability of result pipeline. The bridge vat can use a durable watcher, but that's not resilient to the handler's vat getting upgraded. Alternatively, the bridge vat could pass a promise watcher object along with the reference, but that requires an upgrade of the handler vats to start using.

We have experienced some UnhandledPromiseRejectionWarning in the bridge vat when upgrading the smart wallet for outstanding bid offers. See #10111

These days we have vows that solve that problem. The smart wallet bridge handler would return a vow, that can be watched by the bridge vat.