ci: check direct minimal versions

[ricochet]

Switch minimal-versions CI check to direct-minimal-versions

Avoids failures caused by incorrect lower bounds in transitive dependencies (e.g. native-tls 0.2.12 declaring openssl ^0.10.29 but requiring >= 0.10.46 for Pkcs12::parse2). direct-minimal-versions only resolves our own declared lower bounds to their minimums.

To eliminate another dep to manage, brought in #4171

All workspace Cargo.toml files bumped direct dependency minimum versions to be compatible with transitive requirements:

• memchr 2.4.1 → 2.5.0 (winnow needs ^2.5)
• futures-* → 0.3.31 (futures-util needs futures-core ^0.3.31)
• serde → 1.0.218, serde_json → 1.0.85
• proc-macro2 → 1.0.83, syn → 2.0.87, quote → 1.0.35
• tokio → 1.20.1, time → 0.3.37, uuid → 1.12.1
• smallvec → 1.10.0, bitflags → 2.4, percent-encoding → 2.3.0
• rand → 0.8.5, dotenvy → 0.15.7, plus many others

Essentially looping until cargo +nightly generate-lockfile -Z direct-minimal-versions and cargo build --all-features ran clean.

Aligned all examples to the same minimums, then regenerated Cargo.lock with normal resolver.

Does your PR solve an issue?

This is an alternative approach to fixing CI on main, as opposed to bumping our minimal version for openssl in #4172

Is this a breaking change?

No

[abonander]

Tried re-running CI a few times and it seems that the MariaDB tests hanging is not spurious. I'll try to reproduce it locally.

[ricochet]

While this did take quite a bit of churn to get something that builds, it's totally ok with me if you decide direct minimal versions is too broad or difficult to support.

[abonander]

Re-running an individual check made it pass, which is also weird. It might be a timing/resource exhaustion thing.

I'm unable to reproduce it locally running the exact same commands, but I've got a much more powerful machine than Github Actions provisions.

[abonander]

Okay, it might be a memory exhaustion issue. I ran it with GNU time and got a peak resident memory usage of just over 16 GiB:

        Command being timed: "cargo test --no-default-features --features any,mysql,macros,migrate,_unstable-all-types,runtime-async-global-executor,tls-rustls-ring"
        User time (seconds): 2.38
        System time (seconds): 1.75
        Percent of CPU this job got: 49%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:08.29
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 16770868
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 4
        Minor (reclaiming a frame) page faults: 1529790
        Voluntary context switches: 10988
        Involuntary context switches: 683
        Swaps: 0
        File system inputs: 0
        File system outputs: 0
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0

The ubuntu-24.04 runner only has 16 GiB of memory so it must be overcommitting here. Otherwise it would have aborted with an OOM error.

That would explain why it's so consistent yet I'm unable to reproduce it locally, because I have 64 GiB of RAM in my system.

[abonander]

What's weird though is that on main it uses almost the same, maybe only 10 MiB less. I wonder if that's enough to push it into overcommitting.