Allow `cargo tree` to run despite native library conflicts

[eopb]

Problem

cargo tree can be helpful for debugging dependency trees.

Take this simplified example Cargo.toml:

[package]
name = "foo"
version = "0.1.0"
edition = "2021"

[dependencies]
sqlx7 = { version = "0.7.0", package = "sqlx" }
sqlx8 = { version = "0.8.0", package = "sqlx" }

This crate depends on two major versions of sqlx, which in turn depend on two major versions of libsqlite3-sys. Since both of these libsqlite3-syss link sqlite3, cargo will refuse to build this project:

> cargo check
    Updating crates.io index
error: failed to select a version for `libsqlite3-sys`.
    ... required by package `sqlx-sqlite v0.7.0`
    ... which satisfies dependency `sqlx-sqlite = "=0.7.0"` of package `sqlx v0.7.0`
    ... which satisfies dependency `sqlx7 = "^0.7.0"` of package `hi v0.1.0 (/tmp/tmp.la1oWCFyGQ/hi)`
versions that meet the requirements `^0.26.0` are: 0.26.0

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.28.0`
    ... which satisfies dependency `libsqlite3-sys = "^0.28.0"` of package `sqlx-sqlite v0.8.0`
    ... which satisfies dependency `sqlx-sqlite = "=0.8.0"` of package `sqlx v0.8.0`
    ... which satisfies dependency `sqlx8 = "^0.8.0"` of package `hi v0.1.0 (/tmp/tmp.la1oWCFyGQ/hi)`
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

Since my project is often more complex than this example, it may not be immediately obvious where the dependency on the old version of libsqlite3-sys is coming from. To debug this, I attempt to run cargo tree -i libsqlite3-sys@0.26.0.

Unfortunately, that isn't very helpful:

> cargo tree -i libsqlite3-sys@0.26.0
    Updating crates.io index
error: failed to select a version for `libsqlite3-sys`.
    ... required by package `sqlx-sqlite v0.7.0`
    ... which satisfies dependency `sqlx-sqlite = "=0.7.0"` of package `sqlx v0.7.0`
    ... which satisfies dependency `sqlx7 = "^0.7.0"` of package `hi v0.1.0 (/tmp/tmp.la1oWCFyGQ/hi)`
versions that meet the requirements `^0.26.0` are: 0.26.0

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.28.0`
    ... which satisfies dependency `libsqlite3-sys = "^0.28.0"` of package `sqlx-sqlite v0.8.0`
    ... which satisfies dependency `sqlx-sqlite = "=0.8.0"` of package `sqlx v0.8.0`
    ... which satisfies dependency `sqlx8 = "^0.8.0"` of package `hi v0.1.0 (/tmp/tmp.la1oWCFyGQ/hi)`
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

Proposed Solution

Ignore conflicts due to multiple dependencies linking the same native library when resolving for cargo tree

Notes

No response

[eopb]

@rustbot label Command-tree

[epage]

cargo tree is showing the results from the resolver but in this case, the resolver is failing.

We could potentially solve this by having cargo tree identify that the resolve failed and then running a second, in-memory-only, resolve that disabled links handling. There is the potential for this to make things quite messy due to puncturing through abstractions and risky by having cases that must fail, pass.

If we were to do that, we'd then need to also handle the UX side of this. Kind of like if we solved #10096 as requested, we'd be documenting the command to be showing one thing but we'd instead be showing something else.

If the problem is with the error reporting, we are hopeful that we'll be able to improve that with a new resolver that is actively being worked on. Our issue for that is #5284.