Make futures-lite v1 use futures-lite v2 under the hood

[notgull]

In order to reduce the amount of semver breakage involved with migrating from futures-lite v1 to futures-lite v2, this commit makes it so futures-lite v1 uses futures-lite v2 under the hood. This way, the vast majority of migrations from futures-lite v1 to futures-lite v2 will involve no semver-breakage whatsoever.

Only the future.rs module had any breaking changes, so the rest of the modules are just simply imported from futures-lite v2. future.rs itself mostly just exposes combinators from v2, except for ready, pending and try_zip, which all had semver-incompatible changes.

[fogti]

hm can we test this against the most used crates which depend on futures-lite?

(by using cargo test --config 'patch.crates-io.futures-lite.git="https://github.com/smol-rs/futures-lite.git"' --config 'patch.crates-io.futures-lite.branch="notgull/v2-on-v1"')

• [X] async-std
• [X] blocking
• [X] event-listener
• and a few others which aren't ours (to catch maybe unusual usage)
• [X] gix
• [X] http-types
• [X] isahc (some tests failed for me, but these just tested the CURL version, mine was too new)

[taiki-e]

FYI, I did something similar in portable-atomic before (https://github.com/taiki-e/portable-atomic/pull/99, released in portable-atomic 0.3.20), but many users seemed to prefer using a version where multiple versions will not appear in the lockfile. (Given that 0.3.19 still has more than twice as many weekly downloads as 0.3.20, and that the latest version is selected when lockfile is not present, I suspect that more users actually prefer to use 0.3.19 than above stats. Compatibility issues with cg_clif recently fixed were also reported by 0.3.19 user.)

If we are going to do the same thing also with other smol 1.0 crates, I think we way need to reconsider if it is really worth it.

[notgull]

If we are going to do the same thing also with other smol 1.0 crates, I think we way need to reconsider if it is really worth it.

I think it's worth it for this crate and async-io. For this crate, it has a pretty large public API that didn't change for the most part in v2. So this makes it so the upgrade process from 1 to 2 is a no-op. On the other hand, async-io uses a lot of global state that I want to avoid duplicating if necessary.

but many users seemed to prefer using a version where multiple versions will not appear in the lockfile

Is this an accurate metric? A lot of packages, including ones that aren't updated often, are probably not updating their lockfile routinely.

[notgull]

I'm not as enthusiastic anymore