feat: Django 4.2 support

[fsbraun]

Description

This PR updates djangocms-moderation to support Django 4.2 and 5.0. It is based on the ideas and work of #256 by @Aiky30 .

• If fixes tests so they can run with django CMS 4.0 and django CMS 4.1

  • CMS 4.0: Tests run with djangocms-version-locking
  • CMS 4.1: Tests run with DJANGOCMS_VERSIONING_LOCK_VERSIONS setting set to True.

• Since aldryn-forms does not support Django 4.2, the optional djangocms-moderation.contrib.moderation_forms app has been discontinued.

• Currently, tests against django CMS 4.0 fail (against django CMS 4.1 everything is fine).
  @joshyu: This is not an effect of this PR. Tests failed before already. Do you know why? I would love to get them in line.

Related resources

• Ask: Django 4.2 support and aldryn-forms dependency #257
• [BUG] _get_archive_link does not check the check_archive condition djangocms-versioning#391

Checklist

• I have added or modified the tests when changing logic
• I have followed the conventional commits guidelines to add meaningful information into the changelog
• I have read the contribution guidelines

[Aiky30]

Changes look OK here, although the changes on djangocms-versioning regarding the button looks to be regression that may need to be fixed.

[Aiky30]

Looks to be a regression of functionality in djangocms-versioning 2 where the edit link is disabled vs what appears to have been removed.

[joshyu]

@fsbraun , I create a PR #263
it fixes all check errors and failed tests.

[joshyu]

@fsbraun , about the failed pre-commit-config issue, It is related to the version of isort and other pre-commit plugins.

Freeman and I ever met this errors while fixing another repo.

refer to this:
https://stackoverflow.com/questions/75269700/pre-commit-fails-to-install-isort-5-11-4-with-error-runtimeerror-the-poetry-co

[joshyu]

@fsbraun ,

about the failed tests, it is because that djangocms-version-locking addon create a monkeypatch to override djangocms-moderation.models.ModerationCollection._add_nested_children method, it add a logic to check whether this version is locked. If locked, current children plugins will not be added to the current collection.

I didn't find when versionlock field in version instance is set, so I hard-code the version check and give the different return value.

[fsbraun]

@joshyu Thanks for the explanation. To me, this is very helpful: So that actually is a desired behavior. I also understand FidelityInternational/djangocms-version-locking#80 now (an issue @marksweb raised a while ago)... Let me look into this, maybe we can identical results for CMS 4.0 and CMS 4.1 😃

[joshyu]

@fsbraun,
need your help to fix the left pre-commit error about 0001_squashed_0017_auto_20220831_0727.py file

[fsbraun]

@joshyu Pre-commit now passes. I'd like to look into the version locking effect on the collections with djangocms-versioning 2. Probably need today. Sufficient for you?

[fsbraun]

@joshyu I've updated the tests to test the same outcomes for djangocms-versioning 1 and 2. For most tests that means, removing the version lock before the test. I've also added a test that ensures that locked versions are not added to collections. If you're ok, I can merge.

[joshyu]

@fsbraun ,
LGTM. Thank you for giving such a perfect solution, this is really better than my update on test_view.py.
please help to merge it.

Thanks.