Store client credentials in a new system table

[jsdt]

Description of Changes

This adds a new system table to store the jwt payloads of connected clients. I'm planning to use this system table to expose client claims to modules in subsequent PRs.

The new table is called st_connection_credentials. It is a private system table which stores a mapping from connection_id to jwt_payload. Note that a jwt payload is a json representation of the clients claims, not a fully signed token.

The times when we need to insert and delete these rows closely mirrors that of the existing st_client table, with 1.5 exceptions:

1. We weren't previously inserting to st_client until after the OnConnect reducer ran (even though it was in the same transaction). We want st_connection_credentials to be populated before calling the reducer, so that the reducer can use it get the credentials, so I made a change to insert to st_client and st_connection_credentials before calling the reducer.
2. This difference has not actualized, but when clients start sending refresh tokens, we will probably need to update the credentials stored in this table.

This also enforces uniqueness of connection ids. A duplicate connection id will now make the on-connect reducer fail (since it will violate uniqueness when trying to insert to st_connection_credentials).

Expected complexity level and risk

2.5

Adding a system table is a bit risky. This is almost rollback safe, with one annoying case that is worth calling out:

If a database is created with this system table, opening it with an older version of spacetimedb will only work if there is a snapshot of the database. If we try to load a table without a snapshot, replaying will fail on the first row for that table. This is because we don't write the table schema information to the commit log when creating a database. In practice, this is unlikely to be an issue, because new databases asynchronously trigger a snapshot immediately after creation.

Migrating existing databases will be fine. On startup this will detect that there is a missing system table, and add it in a way that writes it to the commit log. Since it is in the commit log, we can open the database with an older version and still understand the data for that table.

Testing

There are unit tests that cover opening a database created with an older version (which doesn't have this table).

I manually tested opening a migrated database with an older version of spacetimedb.

[gefjon]

I am curious what the bug you alluded to during standup is.

[gefjon]

This all looks reasonable at this stage.

[gefjon]

Please remove the commented-out code. Otherwise this looks good to me. I assume the Unity test suite failures are unrelated, but please verify that.