Switch to sqlx for compile-time checked queries

[jyn514]

A common source of outages is an incorrect query with no tests (#862, #829, #648, etc). While it's good to have tests for all queries, it's not always feasible (especially until #822 is fixed). SQLx offers that advantage that it can check all queries at build time without having to write a test for that specific query. It is also fully async (cc @Kixiron), although that might mean we have to wait until we switch to tokio 0.2.

To avoid needless database connections, this should only connect to the database when a query is changed or added, or a schema change is made: launchbadge/sqlx#249. During CI it should always connect to the database.

[pietroalbini]

During CI it should not connect to the database, or do a build with and without the database: we want to make sure the cached data is correct and a build can work without a connection.

[Nemo157]

By my understanding there will be a separate CLI utility that prepares the queries. So we can run a build job that calls sqlx-cli prepare or whatever the command is, then git diff --color --exit-code to show and fail if any file changed. Then the normal build can run without connecting to the database.

[Kixiron]

I think this’d be a great change, I’ll take a look at it once we’re async-capable

[jyn514]

I have a WIP for this in https://github.com/jyn514/docs.rs/tree/sqlx, using block_on since we're still stuck on iron.

[Nemo157]

(compare link: master...jyn514:sqlx)

[jyn514]

Currently blocked on launchbadge/sqlx#700.

[jyn514]

One footgun I found with this: If a migration fails and leaves the database in an inconsistent state, you can no longer compile the code to fix it, because query! gives an error. I think sqlx prepare should fix that though.

[Kixiron]

The sqlx cli tool can also run migrations, so that can be used to fix anything broken

[syphar]

short update here:
in my axum-experimental branch I came onto two issues trying sqlx:

• composite types in arrays are not supported in parameters & queries ( I believe fixed in 0.7, but i didn't dig deeper on which exact issues / PRs fixed it). We use this for the releases.features field. If this is the only remaining issue we might think about migrating the whole field to JSONB, or wait for 0.7. solved too, I had to manually implement PgHasArrayType here.
• binding arrays to parameters in queries also raised errors, short digging didn't give me a solution, long digging needed. (this is solved)

apart from that the user experience especially with the query! macro is really awesome. Sometimes an nullable field was returned as non-option and this needed tweaking the query to help the sqlx parser.