feat(sever): for test runs, split the failed state into more descriptive statuses

[schoren]

This PR makes the TestRun state more accurate by providing a new set of statuses: TRACE_FAILED, TRIGGER_FAILED and ASSERTION_FAILED.

Changes

• add new states and implement where applicable

Fixes

• Differentiate between a trigger failed state vs a trace failed state in a test run #2285

Checklist

• tested locally
• added new dependencies
• updated the docs
• added a test

[mathnogueira]

Looks good!

[jorgeepc]

Looks good. One question: with this approach, is it safe to assume that if I get a TRACE_FAILED state, the trigger stage was correct?

[mathnogueira]

Looks good. One question: with this approach, is it safe to assume that if I get a TRACE_FAILED state, the trigger stage was correct?

yes. If the trigger fails, the test execution stops

[schoren]

@jorgeepc exactly. The failed stage means that all the previous steps succedded

[jorgeepc]

I think we need to update the OpenAPI specs.

[schoren]

@jorgeepc good catch. updated

[danielbdias]

It sounds ok! Before merging it I have one comment about retro compatibility: should we write a migration or handle in separate the old status to avoid problems with early versions of Tracetest?

[danielbdias]

Today we save this value on our database, right? How will we keep the retro compatibility with older Tracetest versions?
Should we map the old FAILED string as always ASSERTION_FAILED?

[danielbdias]

Or even writing a migration to fix it on the database?

[schoren]

I wouldn't do a DB migration, it is too error prone. Fallbacking to another stata is better I think. Why do you suggest ASSERTION_FAILED? not that I have a better one, but to understand the logic of the choice.