Check direct rust-runtime dependency minimum versions

[goatgoose]

Motivation and Context

The smithy-rs minimal-versions test currently checks all transitive dependencies, which makes it difficult to satisfy the test requirements given that the minimum dependency versions specified in transitive dependencies can't be controlled. This PR updates this test to only check for direct dependencies.

Description

The smithy-rs CI runs the cargo minimal-versions test in the rust-runtime and aws/rust-runtime workspaces to make sure that the rust-runtime crates can still build even when the lowest possible version of each dependency is used. However, the minimal-versions test is not recommended by Rust:

https://doc.rust-lang.org/cargo/reference/unstable.html#minimal-versions
Note: It is not recommended to use this feature. Because it enforces minimal versions for all transitive dependencies, its usefulness is limited since not all external dependencies declare proper lower version bounds. It is intended that it will be changed in the future to only enforce minimal versions for direct dependencies.

direct-minimal-versions can be used instead, which tests the minimum versions of only direct dependencies. This PR updates this test to use the direct variant of minimal-versions.

Dependency minimum version changes

For some reason, the direct minimal-versions check seems to be more strict about direct minimum versions than the transitive variant. Switching to the direct variant caused many cargo update issues like the following:

Cargo update failure example

❯ cargo minimal-versions check --direct
info: running `cargo update -Z direct-minimal-versions`
    Updating crates.io index
error: failed to select a version for `tokio-stream`.
    ... required by package `lambda_runtime v0.8.0`
    ... which satisfies dependency `lambda_runtime = "^0.8"` of package `lambda_http v0.8.0`
    ... which satisfies dependency `lambda_http = "^0.8.0"` of package `aws-smithy-http-server-python v0.63.2 (/Users/vclarksa/w/smithy-rs-fork/rust-runtime/aws-smithy-http-server-python)`
versions that meet the requirements `^0.1.2` are: 0.1.17, 0.1.16, 0.1.15, 0.1.14, 0.1.12, 0.1.11, 0.1.10, 0.1.9, 0.1.8, 0.1.7, 0.1.6, 0.1.5, 0.1.4, 0.1.3, 0.1.2
all possible versions conflict with previously selected packages.
previously selected package tokio-stream v0.1.0

... which satisfies dependency tokio-stream = "^0.1" of package aws-smithy-http-server-python v0.63.2 (/Users/vclarksa/w/smithy-rs-fork/rust-runtime/aws-smithy-http-server-python)
failed to select a version for tokio-stream which could resolve this conflict

error: process didn't exit successfully: /Users/vclarksa/.rustup/toolchains/1.81.0-x86_64-apple-darwin/bin/cargo update -Z direct-minimal-versions (exit status: 101)

It seems that direct-minimal-versions requires that all direct dependencies within an environment be specified with the same minimum version. Additionally, if there is a direct dependency that is also specified by a transitive dependency, the direct dependency must specify a minimum version at least as high as the transitive dependency.

I resolved all such cargo update failures by choosing the highest minimum version specified somewhere in the environment, and applying this version everywhere the dependency is specified.

Testing

The modified check-rust-runtimes test should succeed.

Some of the CI jobs are still failing. However, they appear to be unrelated to this change. These jobs also failed in the last hyper1 commit:

• Verify TLS configuration failed for the previous commit.
• Check for semver hazards failed for the previous commit
• Check PR semver compliance failed for the previous commit.

Also, the canary will need to be run manually if necessary for this change.

Checklist

• For changes to the smithy-rs codegen or runtime crates, I have created a changelog entry Markdown file in the .changelog directory, specifying "client," "server," or both in the applies_to key.
• For changes to the AWS SDK, generated SDK code, or SDK runtime crates, I have created a changelog entry Markdown file in the .changelog directory, specifying "aws-sdk-rust" in the applies_to key.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[goatgoose]

lambda_http was the only dependency that wasn't bumped as a result of the cargo update failure mentioned in the PR description. Rather, 0.8.0 failed to build:

lambda_http failure

    Checking lambda_http v0.8.0
error[E0425]: cannot find function `run_with_streaming_response` in crate `lambda_runtime`
  --> /Users/vclarksa/.cargo/registry/src/index.crates.io-6f17d22bba15001f/lambda_http-0.8.0/src/streaming.rs:33:21
   |
33 |     lambda_runtime::run_with_streaming_response(svc).await
   |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in `lambda_runtime`
   |
help: consider importing this function through its public re-export
   |
1  + use crate::run_with_streaming_response;
   |
help: if you import `run_with_streaming_response`, refer to it directly
   |
33 -     lambda_runtime::run_with_streaming_response(svc).await
33 +     run_with_streaming_response(svc).await
   |
For more information about this error, try rustc --explain E0425.

error: could not compile lambda_http (lib) due to 1 previous error

warning: build failed, waiting for other jobs to finish...

error: process didn't exit successfully: /Users/vclarksa/.rustup/toolchains/1.81.0-x86_64-apple-darwin/bin/cargo check --manifest-path aws-smithy-http-server-python/Cargo.toml (exit status: 101)

error: process didn't exit successfully: /Users/vclarksa/.rustup/toolchains/1.81.0-x86_64-apple-darwin/bin/cargo hack check (exit status: 1)




This was fixed in awslabs/aws-lambda-rust-runtime#723, and released in 0.8.3.

[goatgoose]

The package versions were bumped per check-rust-runtime for crates that were not already bumped as a result of the hyper1 branch changes.

[goatgoose]

I generated the cargo lock files in 1bcf198 before bumping the dependency minimum versions in 92dffbd. I generated the cargo lock files again afterwards, but no updates were made. The only cargo lock file changes made as a result of this PR are due to bumping the rust-runtime package versions. See aa28228 and 5e2cf48.

[landonxjames]

LGTM, thanks for working through the frustration here!

[ysaito1001]

Thanks for the changes.