add "run policy" object to controller.run()

[warner]

This allows the host application to control how much work c.run() does
before it returns. Depending upon the policy chosen, this can be a count of
cranks, or cumulative computrons used, with more details to be added in the
future.

closes #3460

[FUDCo]

It's a little weird that if the return from crankFailed is true the vat should keep going.

[warner]

Does it help to know that it's the kernel which should keep running, rather than the vat? Yeah, at that point the vat is dead. We don't get a lot of data about how long it took the vat to fail: if the vat exceeds its per-crank limit, the process terminates, and all we get is a unix exit status.

[FUDCo]

There's an ambiguity in the interpretation of the name -- it could mean "what do I do if if the crank failed?" or it could mean "did the crank fail?"

[FUDCo]

This seems fine, though I'm left with a lingering sense of engineering without a driving use case (i.e., "this sounds useful" rather than "we need this"). Maybe I've missed some discussions?

[FUDCo]

Seems like there's a role for something that counts cranks but really doesn't care about vat creations. I suppose you could get that by passing Number.MAX_INTEGER_VALUE for maxCreateVats, but I'm left wondering if there should be an explicit "don't care" signal, like 0 or -1 or something.

[warner]

Eh, runPolicies.js is more about providing examples than trying to cover the full range of what sort of policy you might want to implement. Mostly I wanted something to establish the intuition that creating a whole new vat is tremendously more expensive than sending a message to an existing one.

[warner]

This seems fine, though I'm left with a lingering sense of engineering without a driving use case (i.e., "this sounds useful" rather than "we need this"). Maybe I've missed some discussions?

Fair point. #2319 and #2299 contained some of it. Basically we've observed some very long blocks (60s) on the recent testnet phases, and we know that our current policy ("do all the remaining work, every time") isn't viable. At the very least, we know that without a limit on how much we do per block, there's not much point to doing any sort of scheduling / prioritization: none of the cranks we do matter until the block is committed, so the order of txns within a single block is irrelevant (from a priority point of view; certainly there are other benefits to running before/after other txns).

[mhofman]

A bit late to the party, but what I had imagined was to have 2 facets to the run policy. One that can be used by run to ask "should I keep going?", and another facet that can be passed down into the different process methods to inform the policy of actions taken (create vat, crank, etc.). It'd avoid plumbing the "policy input" all the way back up as a return value of process methods, and make some run policies like wall clock very straight forward (no-op for the process facet). The idea was to make the run facet similar to the DOM IdleDeadline API, where the program checks if it has time left to do remaining tasks.