feat: convenient wrapper for Postgres advisory locks

[abonander]

While working on a Launchbadge project, I realized I needed a way to provide mutual exclusion synchronized with the database so that multiple instances of a server application don't try to perform the same side-effecting operation, but the locking scheme I wanted didn't fit neatly onto standard row- or table-level locking.

I excitedly remembered that Postgres has advisory locks with application-defined semantics, but quickly realized they were somewhat unwieldy to use for our purposes.

There's transaction-scoped advisory locks, which would work well except that because I was doing side-effecting operations, I wanted the updates I was making to the database to be published immediately, and it seemed unreasonable to check out two connections from the pool, with one purely existing to hold a transaction for automatically managed advisory locks.

There's also session-scoped advisory locks, which are held until manually released or until the connection is closed. This was better, but because I'm using PgPool I wanted to make sure the lock is released when the connection is returned to the pool. However, some ding-dong (i.e. me) decided that .after_release() didn't need to support async functionality, because... I don't remember why.

So I ended up writing a wrapper that spawns a task on drop to execute pg_advisory_unlock() on the connection before letting it return to the pool, so I could get the project working, but I immediately felt like this should be something that lives in SQLx, and could be more convenient to use and optimally implemented that way.

Thus began a two-and-a-half hour nerd snipe that culminated in this.

TODO:

• integration tests
• more docs (not sure what I meant here)