Check validity of modules before control DB modifications during initial publish

[gefjon]

Description of Changes

Fixes #2577 .

Adds a new method to HostController, check_module_validity. This method instantiates and inits a short-lived module, which will catch various errors that normally would be detected by the automigration planner and executor. This is necessary because initial publishes do not go through the automigration system.

Modifies standalone's publish code to call check_module_validity before modifying the control DB.

Adds a smoketest which does the thing described in #2577 .

API and ABI breaking changes

N/a

Expected complexity level and risk

3? I'm not entirely comfortable with HostController and Host, and so I'm not confident I've done this right. It seems possible that I need some additional secret sauce in order to properly destroy the database in addition to just dropping it.

Testing

• [x] Added a new smoketest which fails prior to this change and succeeds with this change.

[kim]

Hm interesting. The issue isn’t so much that controldb implementations are not transactional, but that the whole publish procedure is not transactional (and can not straightforwardly be).

What exactly is required to check those constraints? Maybe the node handling the publish request can instantiate an in-memory instance before proceeding.

[gefjon]

After discussion with @kim , we intend to revise this PR. (The test will stay unchanged.) Before inserting anything into the control DB, or saving the WASM blob to the program store, we'll build a WASM instance, assert that it sets up correctly, and then throw it away.

[kim]

additional secret sauce

I don’t know how this could be asserted in a test, but it seems very unlikely — no reference escapes and none is retained by the host controller.