The version check does not respect requirements

[PaulDance]

Description If a non-simple version requirement is used and there exists a version of the package newer enough to be outside of the requirement range, the version check reports a new version. That version is therefore displayed and cargo install is still called on it and it results in a no-op.

Expected behavior Only versions inside the requirement range should be considered and the call should not be made if there is no new version inside it.

To Reproduce Steps to reproduce the behavior:

1. Have a config file with the following:

   [packages]
   pastel = "=0.8.0"

2. Run cargo liner ship and let it finish the install.
3. Run it again.
4. See output below.

Output

 INFO  cargo_liner::cargo > Fetching latest package versions...
 INFO  cargo_liner        > Results:
 INFO  cargo_liner        >     cargo-liner  ✔
 INFO  cargo_liner        >     pastel       0.8.0 -> 0.9.0
 INFO  cargo_liner::cargo > Updating `pastel`...
     Ignored package `pastel v0.8.0` is already installed, use --force to override
 INFO  cargo_liner        > Done.

Additional information Fixing this won't be easy: it would need to rework the method used, most probably to move away from cargo search and to use requests to the registry API.

Spawned from #6.

[PaulDance]

The same can be observed when a pre-release is available: cargo-nextest 0.9.61 -> 0.9.62-a.2 although only * is used as a version requirement.

[PaulDance]

I think the easiest would be to simply wait for https://github.com/hi-rustin/cargo-information to be merged directly in Cargo. It already does things intelligently, more so than I would be ready to do at least, and it being merged would mean no optional dependency trouble.

[PaulDance]

Actually, rust-lang/cargo#11123 should be a preferable solution: not the easiest, but should be the best in terms of integration and report precision.

[PaulDance]

Considering cargo-information was recently merged into Cargo as insta-stable and then made available as part of Rust 1.82, using it should be a prime lead to fixing this.

[PaulDance]

• cargo info does not take a full version requirement in, only a specification, meaning the current options would not work.
• cargo install --dry-run takes a full version requirement in, but outputs a lot and downloads all dependencies even if not compiling them, thus slowing down the check, although when already up-to-date it is quite fast.
• cargo search is still not what works either.

Nothing ideal, but further investigation is still needed. Overall though, cargo install --dry-run should actually be the prime lead as downloads would only be done once, not twice. Maybe all methods could be exposed to be chosen by the user, in both a global and package-local manners. Inclusively, all three methods could be implemented, but one would be chosen automatically when the given version requirement fits: search when only *, info when compatible with a pkg spec, and install --dry-run for the remaining cases; auto would be the default value for the option controlling this method.