Improve classification for smatch report converter

[bulwahn]

Describe the bug

We run smatch daily on linux-next and we observe a number of new warnings in the diff every day: as an example, here are all "new" findings in the diff from next-20210507 to next-20210510: https://elisa-builder-00.iol.unh.edu:8001/linux-next/reports?run=next-20210507&newcheck=next-20210510&sort-by=severity&sort-desc=true

Some warnings probably should be considered 'LOW' (or even as background information on the static analysis performance, or sort of diagnostic messages; e.g., can we add a 'diagnostics' type or severity) rather than a warning that needs to be properly tracked in the CodeChecker UI.

I noticed these smatch warnings that are tool performance (analysis) reports, but not really 'real 'findings on the code base that the tool considers to analyse properly:

for 'smatch.smatch_flow'': parse error: Function too hairy. Giving up. [0-9]* seconds for 'smatch.smatch_implied': parse error: turning off implications after 60 seconds for 'smatch.smatch_slist': warn: Function too hairy. No more merges.

We shall consider that we may contact Dan Carpenter, the smatch main developer, to add some further meta information to the smatch output. This was already successful in the past, and he is open to discussion and implementing such features. Maybe start first explaining the issue to Dan Carpenter, and ask what he proposes (maybe we just change the smatch invocation in the build tool chain). Only once that discussion happened, let us check which changes might be needed for the smatch report converter.

CodeChecker version CodeChecker 6.16; as running at https://elisa-builder-00.iol.unh.edu:8001/ .

[bulwahn]

@jay24rajput Please have a look.

[jay24rajput]

As far as I understand the issue, there are some warnings that are of "LOW" severity and should maybe not appear in the CodeChecker WebUI after parsing. For this Dan can maybe modify the "Message" part of these kinds of warnings and then we change our match parser accordingly.

For the unwanted results that indicate tool performance like: 'smatch.smatch_flow''. Maybe we can identify such 'checker_names' beforehand and hardcode these values into the parser for ignoring results with these parser names. But that would require modifying the code( or an external file) every time new checker reporters such results. This feels like a solution we can start implementing right away. @bulwahn are there any other such checker values that might/are causing such errors. Also @csordasmarton what do you think about this?