vat-walletFactory upgrade would cause wallet to stop tracking existing offers

[warner]

Describe the bug

#8286 describes some problems that vat-walletFactory will have upon upgrade, but merges two separate problems. I'm leaving #8286 to capture what happens to vat-walletFactory when vat-zoe is upgraded, and this new ticket captures what happens to vat-walletFactory when vat-walletFactory itself is upgraded:

Similarly, if the walletFactory is upgraded, the code processing the offer will not resume automatically.

The code in vat-walletFactory which subscribes to numWantsSatisfied() and getPayouts() and getOfferResult() (https://github.com/Agoric/agoric-sdk/blob/d4b32f129868ed2faa32f1bcad51b5d2248d4c14/packages/smart-wallet/src/offers.js) is run in a wallet function named makeOfferExecutor, and used by the executeOffer() method. As best I can tell, this is the only time these three subscriptions occurs.

So if an offer is opened in vat-walletFactory incarnation-1, then vat-walletFactory is upgraded to incarnation-2, the new incarnation will not be following any of those promises. The seat might still be active, or it might exit some time after the upgrade, but I don't see any code in vat-walletFactory that would notice.

To resolve this, the wallet needs to either:

• 1: after upgrade, in the new incarnation, iterate through all durably-saved seats and re-establish those subscriptions
• 2: establish those subscriptions with a DurablePromiseWatcher in the first place

Fix 1 will require O(N) time spent shortly after upgrade, as it needs to iterate through all open seats. Fix 2 avoids O(N) work.

To remediate the problem for existing open seats, we need 1. To avoid making the problem worse, we need 2 as well.

Deployment Considerations

We need this fix to be included in the next mainnet vat-walletFactory deployment: we cannot safely upgrade vat-walletFactory without it.