Consider Errors while parsing messages payload

[AmmarAbouZor]

The current implementation of Parser<T> sets the trait bound Display on T which can't fail, but with current situation while parsing SomeIP messages it's possible for a payload to be partly parsed with errors. The current situation is by showing these errors in the message description as text which could be confusing for the users because they can confuse them with the actual log content.

To Solve this issue, we need a way to tell that parsing the payload of a message has some problems, then we can show these errors in the UI in a clean way, like Highlighting the faulty entries and having another tab for errors where the users can jump search the errors and jump to the according log when clicked etc...

To Start resolving this on Rust level we need a way to tell that something went wrong by parsing the payload. One suggestion is replacing the trait bound Display on the Type T in Parser<T> to another trait that have a method that can return a String besides an optional problem field like

/// Trait to replace `Display` for T in parser
trait ToText {
    /// This can increase the performance for parser result types, that never fails since
    /// we can check on it at compile time
    const CAN_ERROR: bool;

    /// Method to be used instead of `to_string()`
    fn to_text(&self) -> ToTextReturn;
}

/// Return Type from to_text() method that have the message beside an optional problem value.
struct ToTextReturn {
    msg: String,
    issue: Option<Problem>,
}

/// Information about the value.
struct Problem {
    severity: Severity,
    msg: Stirng,
}

After that we can keep track on the errors by assigning the line number for each error - similar to attachment - and saving them in memory or to a separate file.

Performance considerations:

With this approach, we are adding an extra check for each line, therefore we need to check the benchmark to measure the impact on that check on the performance.

• One suggested improvement is to attach a constant boolean for items that can't error to roll their checks out at compile time
• Another suggestion is to have the optional Problem boxed issue: Option<Box<Problem>> to save some bytes on each return item in cost of saving them on the heap. This suggestion wouldn't have that much of effect on optimizing the memory consumption since we'll check for the result and drop the empty ones directly anyway.

Another Suggestion:

One more possible option could be shifting nested parsing out of FormattableMessage to somewhere "upper" in the parser itself if that possible.