async flow should support cause chains on errors

[mhofman]

What is the Problem Being Solved?

We're now allowing nested data in errors. While async flow does not enforce that errors have the same message, we should enforce that any other nested data, at least cause, is the same when matching the replay log.

This is in particular useful for our plan of using nested cause for upgrade disconnection. See https://github.com/Agoric/agoric-sdk/issues/9582

Async flow is actually in a particularly interesting position to implement #9582 within its membrane. #10147 is similarly adding async stack traces, but it cannot do that for upgrade disconnection reasons. The async flow membrane could replace the upgrade disconnection reason with an error with the disconnection reason as cause, and attach stack information to it. That requires updating the isUpdateDisconnectionReason to walk the cause chain verifying that the leaf is a disconnection reason.

The main concern is if this error thrown into the guest bubbles back out of the membrane through the result into a vat that uses an older predicate that doesn't support this cause walk. Arguably this fine because this error is terminal anyway (async flow's watch has already decided it wasn't actionable if it let it through to the guest).

Description of the Design

• a deep equal in the membrane log match for throwables that ignores message field of errors.
• an updated isUpdateDisconnectionReason to walk the cause chain
• have the membrane wrap an upgrade disconnection reason into an error annotated with async stacks

Security Considerations

None?

Scaling Considerations

TBD

Test Plan

Throw an error or rejected promise with an error that has an arbitrarily deeply nested cause with an upgrade disconnection reason at its leaf

Upgrade Considerations

Assess compatibility of wrapped errors bubbling out of the membrane

[erights]

See also https://github.com/endojs/endo/pull/2223

Note that the JS standard now has 4 cause-ish Error properties:

• cause for all errors except SuppressedError! (Is this an oversight or by design?)
• errors from AggregateError
• error from SuppressedError
• suppressed from SuppressedError

which raises the questions

• Which chains should we chase to determine if we have a disconnection (or any similar distinction)? I hope the answer remains only cause. But it is bizarre that SuppressedError instance do not have a cause initialized during construction
• Which error properties in general should be considered in determining whether a replay succeeds? Currently we compare only name because we consider all else to be for human diagnostic purposes that should be improvable without breaking replay. This is only strongly motivated for the unredacted portions of message. This issue would add at least cause to this comparison. Should we add all these cause-ish properties to the comparison? What about additional properties we happen to find?
• What should ocapn specify as the round-trip constraints on errors? This should be at least what asyncFlow requires be the same for replay success. But should it be even stronger?