Invoke V8 views from host

[joshua-spacetime]

Extend JsInstance with methods for calling views.

SpacetimeDB/crates/core/src/host/v8/mod.rs

Line 254 in a952ba5

impl JsInstance {

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.