fix(patterns): type guards

[erights]

Subset of #1712 that does not break compat.

Typing and validation for InterfaceGuards, MethodGuards, and AwaitArgGuards.

[erights]

@michaelfig , making you a reviewer because I'm staging my interface-opt-out experiment on this. Let me know if you see a problem with that. I so, I can remove the dependency, but I'd rather not.

[erights]

Note that I'd prefer to stage on #1712 if that were feasible. But I'm scared of the compat break. Eager for your feedback on that too.

[erights]

@turadg Making you a reviewer as I know you've done previous work typing guards. I don't know how that relates to the contents of this PR. What should I look at?

[michaelfig]

Note that I'd prefer to stage on #1712 if that were feasible. But I'm scared of the compat break. Eager for your feedback on that too.

I believe the breaking change in #1712 won't impact any deployed code. IIUC, that's the change of guards from copyRecords to tagged payloads. I can't think of any instance where we put guards in object state or Stores in general, or send them over the network.

If that seems correct to you, I'd encourage you to make the change and stage on #1712. I had just one review comment on #1712, and would be happy to approve after you consider that question.

[erights]

Since #1712 is staged on this, even if we decide we can merge #1712, it doesn't hurt to first merge this PR, once it meets your approval.

[michaelfig]

Approval based on your addressing my comments.

[erights]

Note that I'd prefer to stage on #1712 if that were feasible. But I'm scared of the compat break. Eager for your feedback on that too.

I believe the breaking change in #1712 won't impact any deployed code. IIUC, that's the change of guards from copyRecords to tagged payloads. I can't think of any instance where we put guards in object state or Stores in general, or send them over the network.

If that seems correct to you, I'd encourage you to make the change and stage on #1712. I had just one review comment on #1712, and would be happy to approve after you consider that question.

AFAICT, you're correct re durable state and network messages. However, #1712 seems incompat with some of the code in current agoric-sdk. For example: