Invoke WASM views from host

[joshua-spacetime]

Extend WasmInstance with methods for calling views.

SpacetimeDB/crates/core/src/host/wasm_common/module_host_actor.rs

Lines 51 to 59 in a952ba5

	pub trait WasmInstance: Send + Sync + 'static {
	fn extract_descriptions(&mut self) -> Result<Vec<u8>, DescribeError>;
	fn instance_env(&self) -> &InstanceEnv;
	fn call_reducer(&mut self, op: ReducerOp<'_>, budget: ReducerBudget) -> ExecuteResult;
	fn log_traceback(func_type: &str, func: &str, trap: &anyhow::Error);
	}

This is necessary in order to be able to call views from the query engine. As such, it would be helpful if, as part of this ticket, we made it possible to call into a WasmInstance from the query engine.

Note that while views do not return Results, they can panic. Hence this interface should handle WASM traps so that we can return such errors to clients and subsequently disconnect clients.

We need an interface for the following contexts:

SQL (http/remote query):
This is a read only context. A view in this context can still use a mutable transaction, but it won't update any internal state. It can either fully evaluate the view every time, or it can check if it has a backing table and scan that.

Subscribe:
A view in this context will run in a mutable transaction. If already subscribed to and materialized, it should just return the materialized results. Otherwise we should:

1. Update st_view_arg if necessary
2. Update st_view_client
3. Evaluate the view
4. Update read sets and backing table
5. Return result

Unsubscribe:
A view in this context will run in a mutable transaction. The client is already subscribed so we know the result set is materialized. We should:

1. Scan and return the materialized result
2. Drop the materialized result (delete rows from the backing table)
3. Update st_view_client (remove subscriber)
4. Update st_view_arg potentially (if no one is subscribed to this set of args)

Subscription Update:
A view in this context will run in a mutable transaction. When evaluating a view in this context, we have already checked and determined that the view is stale, hence we are always evaluating the view (not reading cached results) and updating its read set. We also must update the backing table in this case. Note that technically it is not necessary to return the result of the view to the caller because in this case the caller only cares about the table diff which it will get when downgrading the transaction before dispatching to the subscription engine.

[joshua-spacetime]

Update: The host interface should not decide if it needs to materialize a view. Instead the caller (i.e., the subscription engine) should determine that.

The host interface should always assume that it needs to update a view's backing table and read set.

This implies the following:

For SQL (http):
The caller will check to see if the view is materialized. If it is, the caller will not invoke the host api. It will just execute the query against the backing table. If it isn't materialized, the caller will invoke the host api which will materialize the view and its read set. Then it will execute the query against the backing table.

For Subscribe:
Same flow as SQL

For Unsubscribe:
The caller can always assume that the view is materialized, hence we never have to invoke the host api in this case.

For Subscription Update:
The caller determines if a view is stale. If so, it invokes the host api which will update the backing table and read set. The only difference between this case and both SQL and Subscribe is that we have to delete the old rows before inserting the new ones. The caller can be responsible for deleting the old rows in order to keep the host implementation simpler. That is so that the host interface only ever inserts rows into the backing table.