Pascal/refactor error signatures

[Pascal-Delange]

Goal

This PR should be entirely ISO in terms of business logic.
The starting point for me was to remove the GetBoolReturnValue and GetStringReturnValue helper methods on the NodeEvaluation type. The reason for this is that they provided no real simplification over repeated code, because they replaced "null check and type assert" logic by "catch sentinel errors everywhere" logic. Namely, the codebase was a mess of if errors.Is(err, ast. ErrNullFieldRead) {...} else if err != nil {...}.

Continuing on this path, I completely removed the following sentinel errors from the models/ast package:

• ErrNullFieldRead
• ErrNoRowsRead
• ErrPayloadFieldNotFound
  Only ErrDivisionByZero remains as a specific error at runtime, because that should be the only error we really encounter.

Note that old rule dtos ast.ExecutionError can still return the NoRowsRead, PayloadFieldNotFound values and that rules can still have the NullFieldRead status (if they return a nil not a bool).

In the same logic, the models.ErrScenarioTriggerConditionAndTriggerObjectMismatch error, that was possibly returned by EvalScenario and caught higher up the stack for a side effect of "don't create a decision" or "return a 400 error", is dropped in favor of explicitly returning a boolean (for "trigger condition [not] passed")

implementation details

A nasty piece of code that recreated go error types from (integer) ExecutionError DTOs is replaced, decision rule models now hold a proper ExecutionError rather than an error that can be mapped to it.

Bug fixes

• fixed a bug, where test run executions where the trigger condition has changed to become more restrictive would create a noisy error log when the trigger condition does not pass.

Design reflexions

In the end, what this PR attemps to fix is a design that seemed ok at the start but became a horrible mess to memorize, never mind understand.

My take away from it is: using generic sentinel errors to trigger specific side effects at some level of the caller stack is ok in the following cases:

• the returned error is designed to be caught and handled immediately above in the call stack - kind of like io.Reader can return an EOF error that is always handled where the reader is actually read
• the sentinel error is general enough that its use can be relatively universal throughout the codebase, e.g. how we return a 400 at the API level if errors.Is(err, models.NotFoundErr)

but the pattern where a very specific sentinel error is returned by a method down the stack to be hopefully caught several layers above and through module boundaries is a big "no".