result.suppressions property doesn't prefer most current suppressions info during result matching

[harleenkohli]

Originally reported by Nathan Davidson of MS.

Original text:

We’ve encountered what seems to be an unexpected behavior of the SARIF SDK result matching. Not sure if it’s unintended behavior though, or a bad assumption on our side. Here’s the test case:

Given:
• SARIF Log 1 containing Result A, where the suppressions property of Result A is null
• SARIF Log 2 containing Result A, where the suppressions property of Result A is set to a non-null value (like [{ "kind": "external" }])

When:
• Result matching is run with Log 1 as the baseline, and Log 2 as the current

Then:
• (Expected) The suppressions property of Result A in the output from result matching is set to the newer (non-null) value from Log 2
• (Actual) The suppressions property of Result A in the output from result matching is null

Is the stated expectation here valid (meaning there’s a bug in the SDK) or invalid? Since we assumed this behavior, we’re now seeing some suppressed results being filed to ADO as bugs in the case where we’ve already processed an earlier log (which is when we use result matching).