Refactoring of execution activity

[trkks]

Instead of just the ICWE23 hardcoded demo, this should allow more freedom in chaining calls together. Features include:

• /request-history route where the chain of execution can be followed and results of each device read from
• allocating memory for passing non-Wasm-primitive input (e.g. image file contents) to functions
• takeImage callback to host now takes out-parameters, where pointers to the dynamically-sized image and length will be written to
• (complex?) convention(s) for interpreting Wasm function call format:
  • When a function is described with OpenAPI to
    • take in "parameters" that are
      • Wasm primitives, the parameters are passed to the function in received order
      • Otherwise for each one OpenAPI parameter two Wasm are assumed: I. pointer to value in memory II. length of this value in bytes
    • have a requestBody, a file in the request is read into memory and matching pointer+length parameters are assumed
    • respond with data that isn't just a single Wasm primitive, the last two parameters of said function are interpreted as being I. a pointer-to-pointer to the result in memory (this allows module itself to write the value) II. length of the result in bytes
  • Similar interpretation is repeated for files attached to the module at deployment time (e.g. model files like .pb)
  • The "generic" Wasm-function f should then look like this: f([Depl. Ptr+Len], [Arg. Primitive], [Arg. Ptr+Len], [Out Ptr+Len]) -> Out Primitive

[trkks]

Some notes about the merge:

• Because of change in takeImage for supporting dynamically sized images, I ended up changing how the WasmModule is initialized to get hold of module alloc function (e.g. Wasm3Module instantiates first, links second and vice versa on WasmtimeModule)
• Instead of using the ml_model attribute on modules, I opted for just saving a list of "static" (meaning at-deployment-time) files attached to module
• Instead of using the "global" wasm_modules variable, the deployments are responsible for instantiating modules when needed based on ModuleConfigs attached to them.
  • Related to this, it is unclear if making the memory-allocations on runtime in deployment.py might create confusion about which Wasm-module gets to use that memory.