[BLD]: run Rust integration tests in CI

[codetheweb]

Description of changes

Does what it says on the tin. This PR also introduces Nextest, a new test runner (usage during local dev is optional). Nextest is currently 33% faster (when running locally) and has a lot of cool features that we may want to use in the future. In this PR, it's used to segment tests between those that require Tilt and those that do not.

Alternatives

Marking tests with #[ignore]

This is one option recommended by the Rust book. You annotate your expensive tests with #[ignore] and run cargo test -- --ignored when you wish to execute them.

This is simple, but feels very strange.

Using a Cargo feature flag/configuration flag

This was the prior approach and requires adding a build.rs file or updating Cargo.toml for every subcrate that potentially needs access to Tilt. Additionally, the DX isn't quite as nice because tests that require Tilt aren't normally compiled--meaning that you often won't notice that your change breaks some of these tests until you inspect the CI run.

Automatically managing Tilt

The Rust tests could automatically start Tilt for specific tests if necessary and keep the stack warm during tests. This seemed complex and potentially brittle.

Always run Tilt stack for all tests

We could just assume that the Tilt stack is available when running cargo test. This is super simple and imo the best alternative, but it's nice to be able to run the subset of tests not requiring Tilt separately. In CI this translates to faster feedback (starting Tilt is 5-7m) and locally translates to cheaper execution.

Test plan

How are these changes tested?

Tested in CI.

Documentation Changes

Are all docstrings for user-facing APIs updated if required? Do we need to make documentation changes in the docs repository?

n/a

[github-actions]

Reviewer Checklist

Please leverage this checklist to ensure your code review is thorough before approving

Testing, Bugs, Errors, Logs, Documentation

• Can you think of any use case in which the code does not behave as intended? Have they been tested?
• Can you think of any inputs or external events that could break the code? Is user input validated and safe? Have they been tested?
• If appropriate, are there adequate property based tests?
• If appropriate, are there adequate unit tests?
• Should any logging, debugging, tracing information be added or removed?
• Are error messages user-friendly?
• Have all documentation changes needed been made?
• Have all non-obvious changes been commented?

System Compatibility

• Are there any potential impacts on other parts of the system or backward compatibility?
• Does this change intersect with any items on our roadmap, and if so, is there a plan for fitting them together?

Quality

• Is this code of a unexpectedly high quality (Readability, Modularity, Intuitiveness)

[HammadB]

Aa-choo. I have a package allergy.

Thanks.

[codetheweb]

🤧