recreate dynamic vats sequentially, not in parallel

[warner]

What is the Problem Being Solved?

We have three functions in loadVat.js to create a vat:

• createVatDynamically() is used to create a dynamic vat for the first time. It does not wait for the vat to be created, but instead returns the newly-allocated vatID synchronously, so the vatAdminVat which invoked it (via a device) can learn the vatID to wait for.
• recreateStaticVat() and recreateDynamicVat() are used during kernel reboot to reload vats created by the earlier instance. recreateStaticVat() returns a Promise that fires when the vat is fully loaded (which includes evaluating the source bundle). recreateDynamicVat() was not returning a Promise, rather it followed the pattern of createVatDynamically() and returned a synchronous vatID. The code in kernel.js which called it was using await, as if it returned a Promise.

As a result, rebooting a kernel with multiple dynamic vats would attempt to reload those vats in parallel. These vat reloads currently each take ~20s (for a dynamic ZCF vat with metering enabled), and are CPU bound, and the engine isn't multithreaded, so they do not benefit from parallelism (this will change when we have each vat in a separate subprocess). Also, the accidental parallelism interferes with attempts to measure the time each reload takes (to guide optimization efforts).

The task is to change recreateDynamicVat() to return the same sort of Promise that recreateStaticVat() does. This will reload dynamic vats sequentially, just like the reload of static vats.

We'll probably re-introduce parallelism again, once we have each vat in a separate subprocess. But when we do that, it should be deliberate, and justified, and limited (re-loading 200 vats at the same time on a 4-core machine isn't a good idea either).