make TimerService closely held by contracts: remove from terms, Board, home object

[warner]

What is the Problem Being Solved?

If we implement #5798 , then the second step is to remove access to the full-powered TimerService, by doing the following:

• don't publish it to the Board
  • instead, publish the TimerIdentity, which is powerless and safe to widely distribute
• remove the TimerService from the contract's publically-visible terms
  • instead, include the TimerIdentity
• remove the chain TimerService from the batch of chainServices supplied to newly-provisioned ag-solo clients, replacing it with the identity
• when complete, only the core-bootstrap code should hang on to the TimerService in a way that could be provided to new code (via the Big JS Hammer eval() operation)
  • our initial contracts are given access to the TimerService when they are started
  • but no other contracts can get it unless instantiated via the Big JS Hammer

A deeper change, which I think is interesting (but I don't know how much work would be involved) would be to define an Amount-like { time, timerID } structure, maybe using AmountMath.Nat to manipulate it, and change all timer-sensitive contracts (at least the Vault, which needs to compute interest on a particular schedule) to use them. That would remove the TimerID from the contract's terms, and instead include it in each time value that crosses its API.

Description of the Design

Security Considerations

Test Plan

This probably requires updates to the existing unit tests for the components being changed, but maybe not brand new tests, unless we go with the Amount-like "typed-Time" structure.

cc @Chris-Hibbert

[Chris-Hibbert]

I would also want to add a standard check, whenever a TimerService was included in privateArgs, that the TimerService matched the TimerIdentity. Governance handles this kind of thing for Invitations that are governed parameters, but there is little likelihood of wanting the TimerService to be a governed parameter, so it would have to be a parallel utility.

[Tartuffo]

Less coding solution: move timer from terms to private args.

[Chris-Hibbert]

The main tasks are:

1. Zoe
   1.1 Zoe accepts either TimerService or TimerBrand in exitRules
   1.2 Zoe gets a TimerService at boot time, and doesn't accept others in exit rules

2. Contracts
   2.1 Move timerService out of terms everywhere
   2.2 Put it in privateArgs if the contract needs to schedule activity
   2.3 figure out which contracts need to expose a TimerBrand.

3. Bootstrap will need to register TimerBrand and Clock in some public place.

4. zoe/src/contracts
   4.1 priceAggregatorChainlink (clock only)
   4.2 auction
   4.3 fundedCallSpread/pricedCallSpread
   4.4 coveredCall exitRule
   4.5 updateDebt periodObserver,
   4.6 otcDesk exitRule
   4.7 priceAggregator (full)

5. inter-protocol contracts
   5.1 feeDistributor
   5.2 Vault
   5.3 stakeFactory (clock)
   5.4 liquidation

[dckc]

I learned this week that in order to make an offer with an afterDeadline exit rule, the caller has to supply a timer.

For our hackathon project, the only way we figured out how to do that via the smart wallet was to put it on the board.

• timerService: hard-coded boardId (boardAux?) agoric-labs/gimix#4

Looks like addressing that is in scope here.

Zoe accepts either TimerService or TimerBrand in exitRules