Add support for browser platform

[alex47]

Description of Changes

This is a continuation of:

• Add support for browser platform com.clockworklabs.spacetimedbsdk#274
• Add support for browser platform com.clockworklabs.spacetimedbsdk#353

I have applied those changes to the latest codebase.

Added support for the browser platform.

This required:

• Replacing Thread.Start with a Task (Thread.Start is not supported for browser platforms)
  • also made PreProcessMessages async, in order to use Channels async methods
• Configuring the Task to be allowed to run on a separate thread (ConfigureAwait(false))
• Replacing BlockingCollection (which is not supported on the browser platform) with Channel (which is supported on all platforms)
• Configuring the task spawned in IDbConnection.Connect to run on any thread, not necessarily the caller (ConfigureAwait(false))
• Removed Ws.Options.UseDefaultCredentials = true; (this is already true by default. In addition, using this setter is not being supported by browser platforms.)
• Pass the token as query parameter (only on browser platform), as Ws.Options.SetRequestHeader is not supported on browser platform

API

• This is an API breaking change to the SDK

N/A. No changes to the API.

Requires SpacetimeDB PRs

N/A

Testsuite

SpacetimeDB branch name: master

Testing

Testing was performed manually inside of a Blazor WebAssembly Standalone App, using the reference quickstart-chat code.
The test project can be found here: https://github.com/alex47/BlazorWebassemblyChat

• Able to send and receive messages in the Blazor WebAssembly chat client
• Able to send and receive messages in the reference console chat client
• Able to send and receive messages with "spacetime call" command

[CLAassistant]

All committers have signed the CLA.

[bfops]

Thank you for opening this! We'll work on getting it reviewed. One thing I can say is that the .meta files need to be preserved so that the DLLs are loaded properly in Unity. If the new packages need to be loaded within Unity, they'll need .meta files as well.

[jdetter]

It's generally not considered best practice to send an auth token via a URL param. To get around this in our C# (WebGL) and Typescript SDKs we generate a short-lived token which you can generate via an API call. This short lived token is then used instead of your real token. You can see an implementation of this here: (C# SDK) https://github.com/clockworklabs/SpacetimeDB/pull/2988/files and then also here for the typescript SDK: https://github.com/clockworklabs/SpacetimeDB/blob/36f7ca2583a7491285460454839e41ff43ec27a7/sdks/typescript/packages/sdk/src/websocket_decompress_adapter.ts#L93C1-L110C6

I think let's wait for #2988 to land first and see if we can just use the same auth flow that we're using for WebGL?

[jdetter]

@rekhoff Testing requirements for this:

• It cannot break BitCraft or degrade the performance of BitCraft (I don't think it will)
• It cannot break the C#/Unity WebGL support
• I need to see an example of a demo project working in Blazor (or something that uses this)

Impl requirements:

• This needs to handle auth tokens in the same way the typescript SDK + C#/WebGL logic handle auth tokens

[rekhoff]

Changes in 461e245 break all Unity projects, including BitCraft. Without maintaing support for Unity projects, this PR can not move forward.

[rekhoff]

@alex47 Thank you for your contribution!
We have reviewed your PR and unfortunately it doesn't seem to work with:

1. Unity - In Editor/Standalone build (Loading currently throws an error once changes from 461e245 are added)
2. Unity - WebGL builds (Same issue as In Editor/Standalone)

If you're able to fix those issues we'll give this another review,
Thank you!

[jdetter]

Thanks again for the contribution, we haven't heard back in a while so we're going to close this for now but if you end up wanting to move this forward let us know 👍