Add mitigation finding filters and complete mitigation filter tests

[bendnema]

⚠️ Pre-Approval check ⚠️

This PR covers and addresses the existing issue #14558, and is within acceptable contribution scope as a bugfix/enhancement to existing filtering behavior and added/improved tests.

Description

This PR adds mitigation filtering support for Findings and validates that behavior with comprehensive unit tests.

Implementation:

• Adds mitigation_available boolean filtering to finding filters.
• Adds/uses mitigation text filtering (icontains) for mitigation content search.
• Supports filtering semantics:
  • mitigation_available=true → findings with mitigation set (non-null, non-empty string)
  • mitigation_available=false → findings with mitigation unset (null or empty string)
  • mitigation=<text> → case-insensitive partial text matching in mitigation

Coverage is applied across API/UI/report finding filter paths through existing filter classes.
This PR also completes mitigation filter test coverage and ensures test data setup is valid for finding creation and FK constraints, tests can be found in dojo/unittests/test_filter_finding_mitigation.py

Related to #14556

Test results

Executed and passing:

• docker compose run --rm --entrypoint "" uwsgi python manage.py test unittests.test_filter_finding_mitigation -v 2
  • Result: Ran 15 tests ... OK
• docker compose -f docker-compose.yml -f docker-compose.override.unit_tests.yml run --rm --entrypoint "" uwsgi python3 manage.py test unittests.test_finding_group_filter_context -v 2
  • Result: Ran 7 tests ... OK
    Mitigation test coverage includes:
• text matching
• case-insensitive search behavior
• mitigation_available=true/false
• null and empty-string handling
• whitespace behavior
• combined filters
• no-filter baseline behavior

Documentation

No documentation updates required:

• No new parser
• No new model/schema changes
• No new setting introduced

Checklist

This checklist is for your information.

• Make sure to rebase your PR against the very latest dev.
• Features/Changes should be submitted against the dev.
• Bugfixes should be submitted against the bugfix branch.
• Give a meaningful name to your PR, as it may end up being used in the release notes.
• Your code is Ruff compliant (see ruff.toml).
• Your code is python 3.13 compliant.
• If this is a new feature and not a bug fix, you've included the proper documentation in the docs at https://github.com/DefectDojo/django-DefectDojo/tree/dev/docs as part of this PR.
• Model changes must include the necessary migrations in the dojo/db_migrations folder.
• Add applicable tests to the unit tests.
• Add the proper label to categorize your PR.

[dryrunsecurity]

This pull request includes sensitive edits to dojo/filters.py, which were flagged by the configured codepaths scanner as potentially restricted changes. The scanner reported this twice, indicating the file is treated as sensitive and may require special authorization or configuration in .dryrunsecurity.yaml.

🔴 Configured Codepaths Edit in dojo/filters.py (drs_78c225a7)

Vulnerability	Configured Codepaths Edit
Description	Sensitive edits detected for this file. Sensitive file paths and allowed authors can be configured in .dryrunsecurity.yaml.

🔴 Configured Codepaths Edit in dojo/filters.py (drs_348e4a34)

Vulnerability	Configured Codepaths Edit
Description	Sensitive edits detected for this file. Sensitive file paths and allowed authors can be configured in .dryrunsecurity.yaml.

We've notified @mtesauro.

---

Comment to provide feedback on these findings.

Report false positive: @dryrunsecurity fp [FINDING ID] [FEEDBACK]
Report low-impact: @dryrunsecurity nit [FINDING ID] [FEEDBACK]

Example: @dryrunsecurity fp drs_90eda195 This code is not user-facing

All finding details can be found in the DryRun Security Dashboard.