Consider adding 'updated' baselineState

[michaelcfanning]

Feedback from an internal MS results matching effort. In some cases, a result is matched but details of it have been updated in some way that warrants refreshing the already filed work item. For this case, it would be helpful to have an 'updated' baseline state (which indicates the baseline result was effectively matched but something interesting changed about it). It is inefficient to consult the work item server for all 'existing' matches and comparing the filed result against current details. For 'existing' items, no server interaction s/be required. Here are all the possibilities for the work item filer:

1. issue is 'absent': retrieve work item via correlation guid and close it
2. issue is 'existing': no work. issue s/be filed, no refresh required
3. issue is 'updated': retrieve work item and rewrite details or attach a new SARIF log file the reflects more current state
4. issue is 'new': file a brand new work item

To provide a specific example, we have an analysis that analyzes a structural JSON file, looking for bad values in properties. The violation locations are denoted by a JSON path, for example, myObject.myProperty. In some cases, a work item may be filed already against the contents of myObject.myProperty. In a subsequent run, the literal contents of myProperty may have changed (but with the result that the scan tool still objects to them). For this case, we consider the result matched (because it is against the identical scan target, which is owned by a specific engineering team) but want to update the filed item to include new details of what changed.

@lgolding, FYI

[ghost]

Makes sense to me.

[michaelcfanning]

TC suggestion to add 'reintroduced'. rename existing to 'unchanged', updated is approved.

[michaelcfanning]

Schema has been updated for this in SARIF SDK repo.

[ghost]

Changes merged to provisional draft.