[feat] Less strict MSRV enforcement

[FabianLars]

tldr: Let's unpin our dependencies :)

For context the discord discussion i started that lead to this request: https://discord.com/channels/616186924390023171/986184168998330371/1106155646769954867

Note that this request is not about the MSRV itself, though imo we should consider something like "last 1 year of rust releases" in V1, which means we could upgrade to 1.61 in a week. (i don't think 1 year is the healthiest approach, but we can take a more drastic change in v2 instead).

---

Problem

Since v1.0 we regularly had to lock dependencies on minor and patch versions because they upgraded their MSRV to a more recent version than what we promised to our users. In v1.3 we even had to pin time to 0.3.15. After one week we already had at least 2 users facing issues because of this. In this case

1. was caused by gix requiring a min time version of 0.3.19
2. was caused by user-side code being written with APIs from more recent time versions in tauri v1.2 who then tried to upgrade to v1.3

As time goes on we will have to lock more and more dependencies, causing more and more issues for end-users, just because we tried to make it easy for users that actually required a low MSRV (if we're being honest there probably isn't even one that needs a MSRV that low but whatever).

Suggested solution

Going forward i think our approach should be a bit less "forceful":

• No more dependency minor/patch pinning
• Our code should still adhere to our MSRV, so no std apis introduced in newer Rust versions than what our MSRV allows
• Set the minimum version of our dependencies to a version that is compatible to our MSRV. Of course we can't use apis of these crates that were introduced in a version that raised their MSRV too high.
  • Taking time as an example the minimum version should be less or equal to 0.3.15 since that's the last version with a compatible MSRV - in this case 0.3 would be enough.

This way end-users can actually "choose" which MSRV they want:

• If they want the latest of everything and their toolchain is always up to date, then they don't need to care about anything.
• If they want to adhere to Tauri's MSRV for example, they have to make sure all their other dependencies have a compatible MSRV themselves, or with MSRV-dependent dependency version resolution rust-lang/cargo#9930 i guess cargo can potentially take care of that too.
  • For example they could run cargo update --package time --precise 0.3.15 to update their lockfile to make all dependencies use that version of time. Of course this requires that other crates also have to set appropriate minimum dependency versions, but this is not and should not be our problem.

---

One issue with this approach is that we'll likely have to start committing Cargo.lock, primarily to make sure the MSRV workflow keeps working, but i guess this could potentially "soft lock" the dependencies for users too which should be a good thing in this context since that should mean cargo will try to adhere to the lockfile and give users a MSRV compatible version until they run cargo update - this needs confirmation but this is what comments in and around the linked issue above sounded like to me.

Alternatively there's https://doc.rust-lang.org/cargo/reference/unstable.html#minimal-versions which we may be able to use too if we don't want to commit a lock file.

---

This issue was written in the heat of the moment so i may update it later.

[wusyong]

I'm fine with this. @lucasfernog wdyt?
If no one disagree I would like to see a PR or draft to see how it goes.

[lucasfernog]

As long as our CI can pin the dependencies for testing that's fine, and maybe we can outline the MSRV approach somewhere in the docs.

[FabianLars]

For the initial PR in #6966 i went with calling cargo update with the --precise flag for each dependency.

The only viable alternative i can think of right now is to start committing the lockfile, but that sounds annoying to me too x) For an argument in favor of the lockfile see this comment rust-lang/cargo#9930 (comment)

I also tried the nightly -Zminimal-versions flag in a few scenarios like in cargo generate-lockfile or cargo update -p package but it downgraded too far, ending up with broken packages, so that it wasn't able to compile anymore (unrelated to the MSRV).

There's also -Zdirect-minimal-versions but that would still require us to add the dependencies to our Cargo.toml files, but specifying a minimal version, not pinning it to an exact version.