fix: leo test now returns non-zero exit status when one or more tests fail

[mitchmindtree]

Motivation

• Closes [Bug] leo test should exit with a non-zero status code #28971

To-Do

• Add a CliError::tests_failed variant, return it in the case that one or more tests failed.
• Enable capturing exit code in integration test output, and compare it alongside stdout and stderr.
• Add a dedicated test for checking leo test exits with non-zero exit code on failing tests.
• Apply REWRITE_EXPECTATIONS to update existing tests to check exit codes.
  • This needs a workaround: Leo CLI tests should be tested on Linux and Windows not just MacOS #29014 (comment) (just commenting out condition locally seems to work).
  • Pending feat: Add a --disable-update-check flag to leo #29026.

[d0cd]

Looks great @mitchmindtree! Worth mentioning that there's a few places in the CLI where we don't exit with good errors, broadcast failures for one.

[mitchmindtree]

Thanks @d0cd! I'll keep an eye out for these other sites where we should be exiting with nice errors too.

I noticed that the whole process is actually panic!ing on the assertion in the new test here (see the new STDERR expectations). As a result, rather than seeing a non-zero exit code, I'm running into this:

• [Bug] Panic on when using assert_eq on arrays #28992

I've attempted to workaround the VM panic issue by using catch_unwind on the VM deploy step (similar to @mohammadfawaz's workaround in #29022), but it appears the panic! is occurring in a non-UnwindSafe area of code, so the panic! propagates up regardless. I'm finishing up for the day on this end, but I've left some thoughts on the situation here and in the following comment.

I'm thinking I'll remove the new test for now, but leave an issue to re-add once #28992 is addressed.

[d0cd]

It doesn't fix the core issue, but if you adjust the logic so that the assertion isn't trivially false, you should be able to deploy it. One way to do this is make it depend on some input.