Reject clients who match an existing st_client row

[gefjon]

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.

[gefjon]

Marking as draft because I still need to write an automated test for this, but I'm putting it on the back burner as higher priority tickets have surfaced.