Drop django-tagging as dependency

[fopina]

Description

This PR addresses #13161

django-tagging has been replaced with tagulous long time ago, in #3333, including a migration (0066) to copy the tags over. All references later removed in #4419 (migration 0093)
Both of these are merged even before v2.0.0.

I believe this dependency can be safely removed at this point.

This PR removes it from requirements.txt and removes the data-migration from 0066:

• New setups do not even run 0066 as there is a squashed 1-90 (post-v2)
• The squashed 1 to 90 does not include data migration
• The fields are removed in 93, which applies whether squashed is used or not

Release notes v2 updated to highlight the new extra step, for those who haven't updated Dojo in over 5 years (if anyone).

Test results

Only test assertion done is that unit tests execute properly, including running all migrations on a clean database.
I've also temporarily removed the squashed 1-90 migration to make sure 66 was executed without any issues and it is.

I've tried adding some logic to the migration 0066 as in to check whether tags had been migrated or not (and fail otherwise), but I've been unable to "go back" to a version actively using django-tagging.

I have honestly tried in this branch of Dojo v1.11 and fought for quite some time with invalid debian packages and dependency issues (with conflicting requirements due to new versions and lack of transitive dependency pinning).

I ended up realizing that migration 66 (or any other) does not actually delete "tagging" data, so the check I had imagined wouldn't help anyway so I gave up trying this realistic (yet unlikely) scenario

Documentation

release notes for 2.0 updated

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 flake8 compliant.
• Your code is python 3.11 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]

🔴 Risk threshold exceeded.

This pull request modifies a sensitive file (dojo/db_migrations/0066_django_tagulous.py) which the scanner flagged as a "Configured Codepaths Edit" at a failing risk threshold but not set to block. If the change is expected, update .dryrunsecurity.yaml to allow the path or authors; otherwise review the edit before merging.

🔴 Configured Codepaths Edit in dojo/db_migrations/0066_django_tagulous.py

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.

---

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

[valentijnscholten]

Thanks for the PR.

The reason why this data migration (and others) are not present in the squashed migration is:

django-DefectDojo/dojo/db_migrations/0001_squashed_0090_index_duplicate_finding.py

Lines 20 to 37 in 68821a8

	# Functions from the following migrations need manual copying.
	# Move them and any dependencies into this file, then update the
	# RunPython operations to refer to the local versions:
	# dojo.db_migrations.0001_initial
	# dojo.db_migrations.0018_sonarqube_api_integration
	# dojo.db_migrations.0042_risk_acceptance_improvements
	# dojo.db_migrations.0047_jira_minimum_severity_default
	# dojo.db_migrations.0049_create_endpoint_status
	# dojo.db_migrations.0061_jira_webhook_secret
	# dojo.db_migrations.0064_jira_refactor_populate
	# dojo.db_migrations.0065_delete_empty_jira_project_configs
	# dojo.db_migrations.0066_django_tagulous
	# dojo.db_migrations.0069_risk_acceptance
	# dojo.db_migrations.0082_last_status_update_populate
	# dojo.db_migrations.0090_index_duplicate_finding
	# VS 2021-10-09: All RunPython statements above removed, as they are not needed for fresh installs!

I think the idea of the squash was that at some point we can remove individual migrations 0001-0090. But dropping django-tagging is a good start.

@fopina can you rebase/merge dev so we can see if all tests pass?

[fopina]

New setups do not even run 0066 as there is a squashed 1-90 (post-v2)

@valentijnscholten I meant here to highlight the low impact of the change, not to question the decision to not include it 👍 no point having data migrations if there is no data 😄

rebased 🤞

[mtesauro]

Approved