Optimize handling of stacktrace with JITL jobs in case of errors

Current Situation

• When a JITL job fails:
  • The complete exception stacktrace is logged to the agent.log file with logging level ERROR.
    • In addition, the JITL job warnings are also logged in the agent.log with the WARN level.
  • The same full stacktrace is also sent to the Controller API (JOutcome.failed).
    • As a result:
      • The Controller’s own (mini) history of a workflow run is filled with unnecessary information.
        • This increases processing times and memory usage, particularly for failed jobs in Cycle Instructions.
      • The order log captures the same stacktrace at multiple points:
        • [MAIN] [End] [Error]... of [OrderProcessingStarted]
        • [ERROR] [OrderProcessed]...
        • [ERROR] [OrderFailed]
        • ...
        • see order.log.failed-before-JITL-747.log

Desired Behavior

• The full exception stack trace or JITL job warnings should be written to the agent.log file, but with the logging level set to INFO.
• The complete exception stacktrace should be redirected to the STDERR channel of the corresponding JITL job.
  • see  order.log.failed-after-JITL-747.log
• The Controller API (JOutcome.failed) should only receive the exception message, not the full stacktrace.

Test Instructions

• Use various JITL jobs during testing.
• Test different failure scenarios, such as failures due to job execution issues (e.g., inability to establish a database or SSH connection).
• Test failures related to job definition configurations (e.g., exceeding the timeout limit).
• Verify that the complete exception stacktrace is logged only once per failed job in the order log (see log examples).