Implement incremental subscriptions on the client

[jsdt]

Description of Changes

This implements subscriptions to individual queries in the rust SDK.

Most of the logic is in SubscriptionState, which is the source of truth for the state of a subscription. Most of the complexity comes from the use of the PendingMutation queue to delay operations, since some things can change by the time we call that callback.

There are some important followup changes needed:

1. This will not handle queries with overlapping results well (I think it will panic). This shouldn't be a regression from how that would happen with the current API, but it's worth calling out. We need to add ref counting of rows to handle that correctly.
2. Handling of errors for specific queries has a test, but handling a fatal error is not. I plan to implement that cleanup logic in a separate PR.

This also includes a server-side change to actually send SubscriptionError messages.

The corresponding private PR is https://github.com/clockworklabs/SpacetimeDBPrivate/pull/1279.

API and ABI breaking changes

If this is an API or ABI breaking change, please apply the
corresponding GitHub label.

Expected complexity level and risk

3. This is reasonably complicated, since some of the different concurrency cases will be difficult to test.

Testing

There are some basic tests in sdk/tests/test-client/src/main.rs that cover subscribing and unsubscribing to a query, and handling an error from subscribing to an invalid query.

[gefjon]

From out-of-band discussion: what happens if a client calls unsubscribe_then multiple times on (handles for) the same query? My intuition is all but the first call panic, but I'm not married to that. Perhaps related is, what happens if a client calls unsubscribe_then on a handle that has already errored? My intuition is that it's a no-op, but I find that at odds with the first thing.

[jsdt]

From out-of-band discussion: what happens if a client calls unsubscribe_then multiple times on (handles for) the same query? My intuition is all but the first call panic, but I'm not married to that. Perhaps related is, what happens if a client calls unsubscribe_then on a handle that has already errored? My intuition is that it's a no-op, but I find that at odds with the first thing.

In both cases, unsubscribe_then will just return an error. IMO panicking for something like that would be not be very user friendly.

[gefjon]

In both cases, unsubscribe_then will just return an error. IMO panicking for something like that would be not be very user friendly.

I had forgotten that it returned a Result. Returning Err is clearly correct, given that. Hooray!

[kazimuth]

#2163 will also need to be merged in some form if we want to get the C# server module version of Blackholio working. Currently it's based at this branch but if we want to merge this first I can rebase it to master.