Don't reschedule vault's priceNotifier if one exists

[Chris-Hibbert]

refs: #10660

Description

in testing upgrade 18 candidates, we realized that vaultManager was subject to the same error as auctions fixed in #10615.

Security Considerations

No Security implications.

Scaling Considerations

Not fixing this would add a new notifier to the vaultManager's quote watcher for every hour that elapsed between upgrade and the oracles starting to provide price updates.

Documentation Considerations

Unnecessary.

Testing Considerations

This was detected by trawling slogs. It's not clear that we can do better than that to verify the fix.

Upgrade Considerations

It would probably be a mistake to upgrade vaults without this fix.

[warner]

The implementation looks good.

When we upgrade vat-vaultFactory, it will still old a reference to the scaledPriceAuthority's QuoteNotifier from the previous incarnation (because the kernel does not currently know how to safely drop non-durable imports upon upgrade), and that notifier will still send an update to the makeStoredNotifier() and watchQuoteNotifier() from the previous incarnation (because it doesn't know that these clients were ephemeral). But that update will fall upon deaf ears (dispatch.notify() will be ignored), and they won't get new getUpdateSince(). So we'll have a lingering object, but no ongoing activity. If/when vat-vaultFactory or the scaledPriceAuthority vat is deleted, that object will go away.

I'd love it if we could have unit tests on this, which would require mocking the priceAuthority and counting the number of times it receives makeQuoteNotifier() as we trigger it with getCollateralQuote() and friends (and have our mock return errors sometimes). I'll leave it up to you to decide whether that test is worth the effort or not.