Add sandboxed build testing to our CI

[landonxjames]

Recently after adding the crc64fast-nvme crate we have encountered numerous build issues both externally and internally. This was due to an issue in how cbindgen uses cargo metadata and it being an unflagged build-time dependency of crc64fast-nvme (see this issue for details). We missed this in our testing because all of our tests are performed in network-available environments (GH Actions, Codebuild) and so the odd dependencies could still be downloaded even though not initially picked up by Cargo.

To avoid this issue recurring in the future we should add some sort of sandboxed build to our CI to ensure that none of our dependencies will fail in those environments.

Links:

• Customer issue: Announcement: S3 default integrity change awslabs/aws-sdk-rust#1240 (comment)
• docs.rs issue: Request to rebuild docs for the aws-sdk-s3 crate of version 1.70.0 rust-lang/docs.rs#2729
• Various internal issues I can't link to here
• Issue to crc64fast-nvme: Make bindgen optional awesomized/crc64fast-nvme#5
• PR to crc64fast-nvme: Add new c-bindings feature flag awesomized/crc64fast-nvme#6
• Underlying cbindgen issue: Ignore dev-dependencies mozilla/cbindgen#666

[aaronmondal]

@landonxjames LMK if you'd like help or feedback regarding e.g. a Bazel or Nix build. We run many such sandboxed builds for Rust, both via coarse-grained sandboxes (Cargo in Nix) and Bazel (per-action sandboxing).