windsock: add --load-cloud-resources-from-disk and --store-cloud-resources-to-disk

[rukai]

progress towards #1274

Usage of the new functionality

> # Create the resources required to run the benches specified in FILTER and then store the information required to access those instances to disk
> cargo windsock --store-cloud-resources-to-disk "name=kafka shotover=standard size=100KB topology=cluster3"
Creating AWS resources: CloudResourcesRequired {
    shotover_instance_count: 1,
    docker_instance_count: 3,
    include_shotover_in_docker_instance: false,
}
> # Run the benches once, using the instances created in the previous command.
> cargo windsock --load-cloud-resources-file "name=kafka shotover=standard size=100KB topology=cluster3"
Running "kafka,shotover=standard,size=100KB,topology=cluster3"
...
> # Run the benches a second time reusing the same instances
> cargo windsock --load-cloud-resources-file "name=kafka shotover=standard size=100KB topology=cluster3"
Running "kafka,shotover=standard,size=100KB,topology=cluster3"
...
> # Cleanup resources, also remove the resources-to-disk file to ensure that a `--use-cloud-resources-from-disk` command would fail early.
> cargo windsock --cleanup-cloud-resources
All AWS throwaway resources have been deleted

Why we need this?

• improve time to run benchmarks
• more stable results (or at the very least it eliminates a possible source of instability allowing us to more confidently check for other sources of instability)

Design decisions

I intentionally designed --store-cloud-resources-file to skip running the benches.
The benefit of this is it ensures that every time we actually run the bench it uses the same command.
This makes:

• up arrow -> enter in a shell to rerun a bench run more likely to do what the user expects.
• a shell script can loop over multiple benchruns without having to handle the first run differently.

What if we combined the two flags though?
We could just have a single flag --store-and-reload-cloud-resources-file that always writes the cloud resources to disk and loads if the cloud resources file exists.
However there are two problems with that:

1. we need to clear the resource file sometimes when the developer changes the setup procedure for cloud instances therefore invalidating the cached instances.
2. It may not be clear to the developer that cloud resources are left alive with that API. But splitting it up into seperate store and load commands makes it more obvious that it is kept alive and must be manually destroyed.

As such I think the best solution is two seperate commands to give the developer control over when they create and recreate these resources.

refreshing instances
When we reuse instances part of the instance setup should be reused and part should be recreated.
In this PR the shotover binary+config, and the bencher binary will be reuploaded.
However the rest of the setup will be reused as is.
If the developer changes anything else about the setup, say adds a new external dependency then they will have to recreate instances.
I think this is the sweet spot as it lets us iterate on shotover and the bencher performance wise while keeping retries fast and/or avoiding complexity for detecting when we need to recreate other parts of the setup.