Check statusCategory instead of the resolution field for Jira issue status

[derda17]

Description

PR for #14347

The status category is mainly used to decide if a jira issue is active or not. If the status is undefined (this may happen for old Jira projects that have not migrated properly to status categories), the resolution is still being checked. So I kept the most of the original logic for backwards compatibility.
In the resolution check there were some attribute checks missing and the resolution object was compared to a string "None", this always returned False. I adapted this.

Test results

Added a JIRAHelperTest test suite, that test various combinations of status categories and resolutions.

Documentation

I could not find a documentation that needs adjustments. Let me know if there is one.

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.

[derda17]

Some Unit tests failed. I've returned the PR to draft state and will look into the failing tests.

[dryrunsecurity]

This pull request contains edits to a sensitive file (dojo/jira_link/helper.py) flagged twice by the configured-codepaths analyzer as potential sensitive changes; reviewers should verify these modifications against the project's .dryrunsecurity.yaml allowed paths/authors before merging.

🔴 Configured Codepaths Edit in dojo/jira_link/helper.py (drs_cffad6ab)

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/jira_link/helper.py (drs_8795d2db)

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.

[paulOsinski]

I've opened #14716 which addresses the same root cause you identified in #14347 (resolution is unreliable, statusCategory is canonical), but on the inbound webhook side (process_resolution_from_jira) rather than the outbound issue_from_jira_is_active check. Both of these PRs should work together without interfering with each other.