Handle soroban loadgen mode misconfig gracefully

[ThomasBrady]

Description

Resolves #4473

Checklist

• Reviewed the contributing document
• Rebased on top of master (no merge commits)
• Ran clang-format v8.0.0 (via make format or the Visual Studio extension)
• Compiles
• Ran all tests
• If change impacts performance, include supporting evidence per the performance document

[SirTyson]

LGTM, super minor cleanup

[SirTyson]

LGTM! Helpful change :)

[marta-lokhova]

Unless I'm missing where we catch the exception, this change doesn't handle the failure gracefully, does it? The node still crashes. I think loadgen should gracefully fail and the node should continue operating normally (otherwise ssc will be stuck in pod restart loop without displaying any useful info)

[ThomasBrady]

Unless I'm missing where we catch the exception, this change doesn't handle the failure gracefully, does it? The node still crashes. I think loadgen should gracefully fail and the node should continue operating normally (otherwise ssc will be stuck in pod restart loop without displaying any useful info)

Sorry you are right, this isn't "graceful", however I see there being two problems with this flow: the silent/misleading failure ("Aborted (core dumped)") and gracefully propagating/handling the failure. This PR addressed the first part: if someone invokes without running setup they will now get an exception with the relevant error message. An exception is not exactly graceful however. I'm not sure how we can gracefully recover from this while also notifying the user. LoadGenerator::generateLoad returns void; we could print an error and reset the load generator, but if the user is depending on this invocation to succeed, their test will fail regardless. Wouldn't it be better to raise an exception closer to the problematic action?

[marta-lokhova]

Load generator sets loadgen.run.failed on failure, which is used across our test suite and in supercluster (e.g. supercluster observes the metric and fails the mission properly)