simple exchange should handle more orders than fit in the heap

[dckc]

Describe the bug

@dtribble writes:

Something that I think has fallen off our radar for the persistence work is the multiple stages of actually using it. We need something like simple exchange that is order one. And we need vaults to be on disk and not in memory along with their seat and the corresponding structures in Zoe.

• for Zoe, see store Zoe state in durable/virtual objects/collections #4383.
• for Vaults, see Use Virtual Objects in Vaults #4345

That leaves simple exchange. Let's track that here (and postpone it 'till after MainNet-1).

To Reproduce

(IOU a test for crashing the simple exchange by opening more orders than fit in the heap.)

Expected behavior

• O(1) simple exchange that can handle an order book larger than the max heap size

[warner]

This depends upon finishing #2004 and #4255, to provide the virtual/durable collections API in a form that Zoe/etc can use to hold Purses/Payments/other-high-cardinality-things on disk instead of in the heap.

(note that to allow these vats to be upgraded without losing their data, we also need #4325 and for Zoe/etc to store their durable collections in it)

[Chris-Hibbert]

The Zoe part is #4383. I think @turadg is handling Vaults, though I don't see an issue. SimpleExchange is out of scope for MainNet-1.

[dckc]

The Zoe part is #4383.

cool.

I think @turadg is handling Vaults, though I don't see an issue.

#4345 covers it, for my money.

SimpleExchange is out of scope for MainNet-1.

I'm reducing the scope of this to SimpleExchange and postponing it past MainNet-1.

[erights]

To reiterate a point I saw you make elsewhere. The bound doesn't need to be O(1). If the bound is O(log**k N) (polylog) for reasonably small k, that's fine. That gives room to use a great variety of reasonable data structures that would be prohibited by an O(1) requirement.