vat-timer thinks time=0 during bootstrap block

[warner]

PR #7000 caused the loadgen/integration-test to go into a fast loop, partly because the auction code appears to require O(interval) iterations to handle a timequake of interval seconds, but equally partly because our chain startup code thinks that the current time value is "0" during the execution of the bootstrap block.

Time only updates between block boundaries, so every interaction with the TimerService during bootstrap will see the same time=0 vaue. Then, after bootstrap finishes, just before block-1 starts, the host application does a poll(blocktime), which updates the device's view of the current time. All the timer interactions during block-1 will see this new value, which of course is roughly 1.7 billion seconds larger than 0. This discontinuity may be surprising to code that assumes it will be woken up promptly.

We need the auction code (and all code that uses the TimerService) to handle such timequakes smoothly. But it would also be nice if the bootstrap block had a better idea about the current time.

When swingset is starting in a new chain, the genesis.json data (which is within consensus, and is indeed the very definition of initial TOFU-style consensus) includes a genesis_time field. This seems like a reasonable initial value for the timer device to use.

When swingset is being reinitialized in an existing chain (our upcoming "bulldozer upgrade", we want to use the blocktime of the most recent block, instead.

We aren't yet sure of the best way to get this tme value into the devce. One thought is to call poll() early, before the first controller.run() has a chance to execute the bootstrap message, however poll() depends upon some callbacl wiring code that may not have executed yet.

Another idea is to include the initial timestamp value as one of the timer device's deviceEndowments (which usually hold functions, but could hold plain data just as easily). The trick there is to not accidentally cause consensus problems after the initial step: each time we restart the validator, we'd be passing a different value into this endowment, but the device should only pay attention to it when it does not already remember the latest timestamp.