Add Performance Regression Testing [Rust]

[nathaniel-may]

resolves #3054

Description

Adds the first iteration of performance regression testing. The test suite consists of the following components:

1. Target dbt projects that demonstrate performance strain
2. Rust runner with target dbt commands, and regression detection logic
3. Github Actions workflow for orchestration across branches

These tests will run nightly via github actions, and can be triggered through the UI. They will run all of these commands on all of the dbt projects with dbt installed from develop and with dbt installed from our baseline branch which is currently set to 0.20.latest. It will trigger a failure if the dev branch is slower than the baseline version by a set threshold. Failures could be reported via email, slack and whatever else we think of.

This PR is the first to include Rust in this repo. However, you can rest assured that contributors do not need to install the rust tool chain to continue contributing to dbt. this code relies on dbt, not the other way around.

This PR Is to be merged with the dummy projects. The regressions it is catching now are likely due to the fact the dummy projects do not induce any stress on dbt and thus have pretty high variance in their run times. Immediately after, I will put up a PR with at least one real project that may have thousands of files, but no other changes. From there the exact threshold numbers may still need to be tuned, but the variance in run times should be far more reasonable.

Suggested Path to Review this PR:

1. Look at .github/workflows/performance.yml. This is the highest level orchestration of the tests and outlines the workflow of how we are conducting these regression tests
2. Look at performance/runner/src/main.rs. This is the entry point to the rust runner that we saw in the github action. It has two sub commands measure and calculate. First look at the exit criteria here before moving on to the implementation of these sub commands.
3. Look at performance/runner/src/measure.rs::measure since this is the entry point for the sub-command that is called first in the workflow.
4. Look at performance/runner/src/calculate.rs::regressions since this is the entry point for the other sub-command.

Requested Feedback

• At the highest level, is this approach the way we want to do this? If there's an alternative way you think we should try, now is the time to say something.
• Are there any improvements I can make to my github action workflow? I'm not a power user yet and I would love to see if there are any improvements we can make to this one.
• Look at the output of the action. Are there any changes to the artifacts or stdout that you would like to see?
• Where should I add more comments? I especially want to add comments to places if you don't know why something is happening.
• Is any code particularly ugly? I love a good refactor.
• Are there any places you think might be particularly terrible to debug? I tried my best to make our future debugging efforts as painless as possible.
• Anywhere that my Rust could improve. I'm not fluent in all the corners of Rust yet so if you see something I could be doing better, let me know.

TODO:

• define precise failure characteristics
• test actions workflow
• write result comparison logic
• use a real arg library
• remove PR workflow trigger (intended for development only here)
• add error on warning to the test runner job
• [Optional] pull commands from json config file instead of hard coding in source

Checklist

• I have signed the CLA
• I have run this code in development and it appears to resolve the stated issue
• This PR includes tests, or tests are not required/relevant for this PR
• I have updated the CHANGELOG.md and added information about my change to the "dbt next" section.