Reimplement: Reject clients who match an existing `st_client` row

[clockwork-labs-bot]

This issue tracks reimplementation of the work from stale PR #2748, which is being closed because it is too out of date to merge directly.

    Original PR: https://github.com/clockworklabs/SpacetimeDB/pull/2748
    Original author: @gefjon
    Original branch: `phoebe/reject-duplicate-st-client-connections`
    Base branch: `master`

    ## Original PR summary

    # Description of Changes

At various places in our codebase, we assume that client connections are unique by (identity, connection_id) pair,
but we never actually enforced this prior to now.
It was difficult, but not impossible, to accidentally connect with an already-present (identity, connection_id) pair. The easiest way was to open two DbConnections in parallel from within a single Rust client SDK process,
due to a misbehavior in that SDK which I intend to fix in a separate PR.

This commit modifies MutTxId::insert_st_client to return an error if the row to be inserted is already resident in the database. It's still possible for a database owner to delete from st_client manually via a SQL delete statement, which will cause strange misbehaviors, but it should no longer be possible for an unprivileged client to accidentally put the database into a state that's intended to be impossible.

API and ABI breaking changes

N/a

Expected complexity level and risk

1

Testing

• Manually tested with a modified quickstart-chat client.

  • Prior to this commit, the host accepts both connections, sends responses only to the first one, and shows the error log introduced by Log instead of panicking when missing a row from st_client #2722 when the second disconnects. (Or maybe when the first disconnects? Timing unclear.)
  • With this commit, the host rejects the second connection, and so none of the misbehavior is reachable.

• Write automated tests somehow.

    ## Follow-up
  
    - Reimplement this change in a fresh PR against current `master`.
    - Carry forward any still-relevant context from the original PR discussion and review.
    - Link the new implementation PR back to the original stale PR for historical context.