Raise libsqlite3-sys dependency from 0.30 to 0.31

[dtolnay]

This makes it possible to use sqlx and the most recent versions of the cargo crate in the same dependency graph. Cargo depends on rusqlite 0.33 which uses libsqlite3-sys 0.31. Without this PR, this dependency graph doesn't work.

error: failed to select a version for `libsqlite3-sys`.
    ... required by package `sqlx-sqlite v0.8.5`
    ... which satisfies dependency `sqlx-sqlite = "=0.8.5"` of package `sqlx v0.8.5`
    ... which satisfies dependency `sqlx = "^0.8.5"` of package `repro v0.0.0`
versions that meet the requirements `^0.30.1` are: 0.30.1

the package `libsqlite3-sys` links to the native library `sqlite3`, but it conflicts with a previous package which links to `sqlite3` as well:
package `libsqlite3-sys v0.31.0`
    ... which satisfies dependency `libsqlite3-sys = "^0.31.0"` of package `rusqlite v0.33.0`
    ... which satisfies dependency `rusqlite = "^0.33.0"` of package `cargo v0.87.1`
    ... which satisfies dependency `cargo = "^0.87"` of package `repro v0.0.0`
Only one package in the dependency graph may specify the same links value. This helps ensure that only one copy of a native library is linked in the final binary. Try to adjust your dependencies so that only one package uses the `links = "sqlite3"` value. For more information, see https://doc.rust-lang.org/cargo/reference/resolver.html#links.

failed to select a version for `libsqlite3-sys` which could resolve this conflict

Is this a breaking change?

The libsqlite3-sys update: no, previous precedent is that these are semver-exempt and anyone using libsqlite3-sys through some other dependency needs to have pinned their sqlx version and be updating in lockstep.

sqlx/CHANGELOG.md

Lines 888 to 890 in 91d26ba

	* Alongside this upgrade, we are now considering the linkage to `libsqlite3-sys` to be **semver-exempt**,
	and we reserve the right to upgrade it as necessary. If you are using `libsqlite3-sys` directly or a crate that
	links it such as `rusqlite`, you should pin the versions of both crates to avoid breakages from `cargo update`:

However, for this specific update, libsqlite3-sys requires a version of bindgen that only supports Rust 1.82+, and sqlx considers this a breaking change.

sqlx/FAQ.md

Lines 23 to 24 in 91d26ba

	SQLx's MSRV is the second-to-latest stable release as of the beginning of the current release cycle (`0.x.0`).
	It will remain there until the next major release (`0.{x + 1}.0`).

If a new major version of sqlx is not imminent, I am still interested in libsqlite3-sys 0.31 in sqlx 0.8 and can make it not a breaking change by improving bindgen to generate Rust 1.78-compatible code when run by a toolchain older than 1.82.

[abonander]

@dtolnay would it be acceptable to close this in favor of a bigger bump to 0.34/0.35: #3922 (comment)

[dtolnay]

With #3922 there is still no way to use a recent version of cargo and a recent version of sqlx in the same build graph. There is no version of cargo that is compatible with libsqlite3-sys 0.34 or 0.35. By skipping from 0.30 to 0.35 you would be leapfrogging all the versions that do not conflict with cargo. It would remain the case that the most recent published release of cargo that is possible to use in the same build graph as a published version of sqlx would be 3 Rust toolchain releases (4.5 months) out of date.

My preferred policy would be if sqlx could commit to hitting every libsqlite3-sys release, not skipping ahead more than one version at a time. For example you might publish sqlx 0.9.0 compatible with libsqlite3-sys 0.31, sqlx 0.9.1 compatible with libsqlite3-sys 0.32, sqlx 0.9.2 compatible with libsqlite3-sys 0.33, etc. Even if those are published on the same day within minutes of each other. This allows codebases constrained on libsqlite3-sys version (such as by cargo) to always be able to pin a sqlx version compatible with that.

[abonander]

What if we started using version ranges instead? There's generally never any changes that break our usage. Why does libsqlite3-sys always do a minor version bump, anyway?

[dtolnay]

In my experience range dependencies have been universally a bad idea in every project that has tried them. It leads to dependencies that flap unpredictably and uncontrollably between different versions when touching unrelated dependencies and when using cargo update --aggressive, leading to spurious confusing Cargo.lock diffs. In particular, Cargo's behavior is not that it resolves ranges to the largest version compatible with all the constraints from elsewhere in the build graph, which would be most people's expectation if they have not dealt with range-related problems before.

That said, I don't think my experience covers a version range for a dependency that uses links. I am willing to believe that in this case it would be okay because one can add their own (unused) dependency on a specific libsqlite3-sys version, and since only one version of this crate is allowed in the build graph by links, this deterministically controls the version of libsqlite3-sys that sqlx would pick up. With CI to verify sqlx really does work with every libsqlite3-sys version in the range, my guess is it would be okay.

[abonander]

Yeah, I think it should work fine because it's exactly what Diesel does: https://github.com/diesel-rs/diesel/blob/cdf7c51c35da7ebc6fb12e71857bfba8487c20cd/diesel/Cargo.toml#L53