test that v48-vaultFactory re-subscribes to timer when v48-vaultFactory is upgraded

[warner]

As part of #8499 (comment) (look for v5-timer-v23-feedistributor-v48-vaultfactory), we're investigating how v48-vaultFactory will react when it is upgraded, in particular whether it will re-follow the timer service notifiers it uses.

v48-vaultFactory has code which talks to the timer service and creates a notifier during helper.start(). The timer service provides durable notifiers, and this subscriber code correctly uses observeNotifier to react to vat-timer being upgraded (and the individual promises being disconnected). The remaining important property is that the subscribing code (in v48-vaultFactory) correctly handles itself being upgraded, by re-subscribing or restarting the timer notifier.

It looks like this is designed to happen correctly, by virtue of helper.start being called by provideAndStartVaultManagerKits, in a loop which suggests that all existing kits will be restarted when v48-vaultFactory is upgraded. This is probably called from prepare, which indicates the contract is designed for upgrade.

(I suspect this is all working, but if not, it would be a blocker to upgrading v5-timer. Someone who knows what is tested and what is not may be able to trivially close this ticket)

The task is to test this tolerance of upgrading v5-timer, probably through a3p:

• set up a vault factory, which will establish the timer loop
• upgrade the vault factory
• assert that the vault factory has re-subscribed to the timer service
  • perhaps by allowing time to advance and then observing the vault factory reacting to the passage of time correctly