fix(filter-triage logic): include Mitigated, update the products tally

[alex-ter]

EDIT:

I think I've found all the necessary pieces of the puzzle and it all essentially boils down to fixing/adjusting the --filter-triage switch logic: take the Mitigated remark into account, and update the product CVE tally.

With these corrections, the tool's exit status is now correctly reflecting the triaged CVEs, and the test_requirements.py can be adjusted to get rid of those custom/disabled pieces.

This change is useful beyond that test, so is still meaningful even in view of its potential removal as described in #4294.

Tested this manually by including a dependency with a CVE, and triaging it using the TRIAGE.json.

Let me know what you think.

Original PR description follows for context, but it's less relevant now, the above covers it.

---

The test_requirements.py test used a custom logic block to implement what is essentially the --filter-triage switch now, with one minor difference - the Mitigated part was omitted from the latter.

Add Mitigated to the filter-triage list, and use the switch in the test.

I've stumbled upon this while reviewing #5465 and a commented out piece mentioning #1752 caught my attention, so I went down the rabbit hole.

That one is still open and I need to gather more information to open either a proposed PR or an issue to discuss it first. There's certainly some logic duplication and discrepancy, and the exit status is still not 0 when all CVEs are marked as mitigated/inapplicable, even though #1752 is closed by now.

While investigating the above I realized we can (and I think - should) get rid of that custom logic block in the test, now that we have a native feature for that. That required an adjustment in the filtering logic itself, but I think Mitigated makes sense in that list - let me know what you think.

[alex-ter]

EDIT: this comment is less relevant now, left here for the context and capturing the chain of thought. See the PR description following the "EDIT" remark for the most up-to-date information.

---

Hmm, thinking more about it, this is probably a WIP material, as having this change without fixing that status code logic and uncommenting the assert related to that in the test leaves us with one that doesn't have any asserts and therefore is not doing its thing properly.

Ok then, let's use it as the discussion vehicle - please let me know what you think about that filtering logic addition (Mitigated) and whether you think the direction makes sense here, assuming we'll correct the return status piece.

BTW, that logic block I've removed from the test doesn't fully work anyway - those remarks end up in the output JSON without spaces actually (e.g., NotAffected, not Not Affected), so even if we wanted to keep this logic without uncommenting the return code-based assert, the right way would be to canonicalize the loaded Remarks into the enum proper for comparison (I've tested that while exploring this).

[alex-ter]

I believe this is now ready for review. Adjusted the PR description with the final conclusions, leaving the old one in place for context.

Please let me know what you think.