Add invariants on Wasm Execution

[mariaschett]

Oak Function leverages and relies on Wasm and wasmi to isolate one user request from each other.

We have the following invariants:

• Oak Functions executes Wasm code triggered by a user request in ephemeral sandboxes.
• Wasm code can only communicate with Oak Functions through a restricted interface: the Oak Functions ABI. The restricted interface does not allow Wasm code to (i) persistently store data, or (ii) communicate with other Wasm code.
• wasmi allocates its own and exclusive (linear) memory to every execution of Wasm code.

We need to clarify whether executing two user requests in parallel can lead to contention-based side channel attacks, but for now, Oak Functions only executes a single user request at the time.

I want to state the invariants in a README in oak_functions/wasm and connect to our code, simlar to the invariants for lookup data.

Related: #3449 .

Anything missing @conradgrobler @tiziano88 ?

[conradgrobler]

A few detail points:

• Each request has its own ephemeral sandbox (they are never reused)
• The Wasm sandboxes are ephemeral because the linear memory for each instance is created from a vector that is zero-initialised, and each sandbox is detroyed when the Wasm execution completes
• We should probably also highlight the point that the linear memory is an isolation boundary because the Wasm execution model means that Wasm code has no ability to access memory outside of the linear memory of its current instance

[mariaschett]

Nice!

Maybe also related are our reasons for choosing wasmi as interpreter.

[mariaschett]

We should also add the limitation that Oak Functions is currently not able to terminate the execution of a request.

Furthermore, as a precaution, the Oak Functions ABI does not expose any kind of timing functionality to the request's logic.

[mariaschett]

Related #3079