Use advisory lock when assigning sequence IDs

[richardhuaaa]

Hoping for this to be an invisible change - relying on existing unit tests for verification.

Whenever we add a table that relies on a sequence for ordering, we should consider adding a Postgres stored function that performs insertions by taking an advisory lock first. This ensures that inserts on the table are processed serially.

For these stored functions, I've matched the params and param ordering to the existing queries. I also allowed unique constraint errors to bubble up rather than specifying ON CONFLICT, to match the existing queries.

The dev/up script also generates the protos, and I don't see a convenient way to exclude the protos for the replication project. However, I assume that at some point we will need them on this server, for forwards-compatibility purposes.

[richardhuaaa]

Just realized the generate script doesn't actually re-generate the queries, so I haven't actually tested the new queries. Will fix that, oops!

[neekolas]

With the way this is queried, do we actually care that the group_messages table IDs are globally monotonically increasing. What if we made the lock key the group_id instead?

Unlike with replication, no one is querying across multiple groups.

Same goes for welcome messages.

We could get away with doing the same for inbox logs too, even if there is a bit of a global namespace for those because of the address mapping. But that doesn't rely on the sequence_id being monotonically increasing, so I think it's fine to have that lock be scoped as well.

[richardhuaaa]

Great nuance @neekolas, this gives us more concurrency.

Some implementation notes:

• We are using hashtext in other places in this repo too, so I chose to use the same thing. hashtext is faster than md5 and the result fits inside a 32-bit int, however it is a postgres-internal function that is not documented (I think it's used internally for indexes). That means its implementation may change between Postgres versions. I think that shouldn't cause any problems for us when used for a lock, but if we are concerned, we can always switch to md5.
• The performance of hashtext is likely not a problem, especially given we are now locking per log, but at some point we should benchmark the throughput we can get per log with this locking strategy. If the hashing is a problem, worst case we can use a simpler hash that allows more collision, hardcode some constants, or generate the hash outside of the database.

[neekolas]

We could cut down on the number of hashes by concatenating the two strings before hashing if we're concerned about perf

[richardhuaaa]

Another good option if perf becomes an issue. Separated it for this implementation to reduce collisions (especially against other tables)