[stress testing] Improve UX and sub-command usage of stress deploy scripts

[benbp]

See https://github.com/Azure/azure-sdk-for-net/pull/28320#discussion_r855675487

We should support more fine grained operations in dev usage of the stress scripts. Right now the script is written with the approach that its goal is to build and deploy a stress test to a cluster. However, it would be more useful to take an approach that focuses on automating various operations, like deploy, build, buildImage, debug. For example, we have some custom configuration around building of dockerfiles with external directories. In order to find the correct docker command you have to run the deploy script and copy the command from the log output. It would be better to just provide a sub-command or function like buildImage for this case.

Operations I can think of that we do today, some via the script and some manual:

• build (building the stress code, perhaps we should provide a common build script hook for this)
• buildImage (build the docker image)
• pushImage (push the docker image)
• run (run the docker image, this may be trickier or unnecessary since we haven't prioritized local flows given the ease of using k8s)
• debug (ssh into the container and/or attach a debugger to a container process? This is probably its own feature/issue)
• logs (tail the logs from an active stress test)
• show (show all active instances of this test)
• login
• template (helm template, validate stress config)
• deploy (normal operation of the script, login/build/push/helm install)
• deployAzure (deploy the bicep template, so that people can run locally against a static set of resources)
• uninstall/remove (remove test from cluster)
• dashboard (open dashboard links, etc.)
• docs (open docs)
• useLocalConfig/useRemoteConfig (switch helm repo under the hood for local addons dev)
• init (this could use the stress generator, or just create a boilerplate gitignore/dockerfile/templates/chart.yaml/etc.)

[richardpark-msft]

This should be considered super long term stretch goal, IMO. If anything the script can just print out the proper command lines for some of these things (ie, dry-run).

[benbp]

A full overhaul of the text UI is a stretch, but I think there are some operations that would be helpful to add today, like image build only, use local addon, and show test.

In my experience, people rarely look at or discover the command line output or would know which ones can be run standalone.