quickstart readiness check failure leads to confusing situation

[qrkourier]

I needed to reconfigure my firewall before the expressInstall readiness check could succeed. I needed to follow the quickstart reset procedure because I couldn't find a way to re-try the readiness check to resume expressInstall.

The reset only takes a little bit of time if you know the steps, but I had to hunt down the doc to figure out how to do it, so there was some confusion and wasted time we might be able to save if I'd known that I needed to do the reset.

I shouldn't have ctrl-c canceled the readiness check (controller's edge port check) because it will keep checking until it succeeds. Still, I didn't know better then, so I found myself in this position.

One way to provide guardrails would be a signal trap. When the user cancels the readiness check, we could print some helpful info like "You will need to reset the quickstart and try again because there's no way to resume."

[qrkourier]

Alternatively, it would be a good experience if subsequent runs of expressInstall noticed that ZITI_HOME exists and offer to resume the install procedure or perform the reset procedure. A reset option is more useful than merely unsetting quickstart env vars.