`models` module replaced by a `models` package containing an `abstract`
module (for abstract models) and a `generic` module (for the default
models, previously in the `models` module)

---

Resolves celery#305

Fixes celery#314

… module.

Added some minor changes.

---

Resolves celery#305

Fixes celery#314

* Fixed import bug

Co-authored-by: Allex <a.veldman@chain-stock.com>

Added a `helpers` module into `models` containing the functions
`taskresult_model()` and `groupresult_model()`.

  * `taskresult_model()`: will try to find the custom model using a
    dotted path defined under the constant
`CELERY_RESULTS_TASKRESULT_MODEL` in the settings of the user's project
  * `groupresult_model()` will try to do the same using under the
    constant `CELERY_RESULTS_GROUPRESULT_MODEL`.

By default if these attributes are not found `django-celery-results`
will use the default models (`models.TaskResult` and
`models.GroupResult`).

Updated database backend in order to use custom models for `TaskResult
and `GroupResult` it they're present.

Instead to import explicitely the `TaskResult` and the `GroupResult`
(default models from `django-celery-results`) we make use of the model
helpers to load the right classes, the custom ones if they're present
otherwise we use the default ones.

Getting data from `task_kwargs` to extend the `task_properties` and be
able to store them into the database (using the custom models).

First of all we need a way to get data from `task_kwargs` (or somewhere
else) just before a `task_result` record is created, evaluate that data
and find the right values that will be used to fill the new fields
defined in the custom model.

So for this purpose we added a settings module to
`django-celery-results` which will hold default settings, the first
setting that will contain is a function in charge to get a callback from
the settings of the user project. This callback will be feeded by the
task `task_kwargs`, which will be intercepted in
`DatabaseBackend._get_extended_properties` just before the `task_kwargs`
are encoded by `encode_content()` method and send it to the
`store_result` method from the object manager of `TaskModel`
(Custom/Default one).

To end, we must to extend the arguments of the `store_result` method
from the `TaskResult` Manager adding `extra_fields` argument that will
make us able to send extra data to the custom model, when it's defined.

---
Resolves celery#305

Fixes celery#314

`extend_task_props_callback` moved from `_get_extended_properties`
to `_store_result`. Suggested by @AllesVeldman.

`extend_task_props_callback` will get the `request` object as first
parameter and a copy of `task_props` (avoiding potential manipulation of
the original `task_props`) as second paramenter.

---
Resolves celery#305

Fixes celery#314

`get_callback_function()` gets a default callback as an arg
returning explicitely an empty dict.

`get_callback_function()` raises an `ImproperlyConfigured`
exception when the callback is not callable.

---
Resolves celery#305

Fixes celery#314

Added `get_task_props_extension` to `settings` module which will raise
an `ImproperlyConfigured` when the task_props_extension doesn't complies
with the Mapping protocol.

`DatabaseBackend` will make use of `get_task_props_extension` to update
a potential custom model with the custom properties

---

Resolves celery#305

Fixes celery#314

…ttings.

A new page added to the documentation where we explain how to use this
feature.

--

issue: celery#305

pull-request: celery#314

for more information, see https://pre-commit.ci

…in `django_celery_results.settings`


Fixed a "wrong" description for the `ImproperlyConfigured` exception raised when `task_props_extension` doesn't complies with the Mapping protocol. At this point `task_props_extension` is just a dict that inherits from Mapping, not an explicit instance.

Thanks @AllexVeldman

Co-authored-by: Allex <a.veldman@chain-stock.com>

Co-authored-by: Allex <a.veldman@chain-stock.com>

Co-authored-by: Allex <a.veldman@chain-stock.com>

Co-authored-by: Allex <a.veldman@chain-stock.com>

- Added new abstract model `AbstractChordCounter` in `abstract.py` for Chord synchronization, including fields for `group_id`, `sub_tasks`, and `count`.
- Updated `ChordCounter` model in `generic.py` to inherit from `AbstractChordCounter`.
- Moved `group_result` method from `ChordCounter` to `AbstractChordCounter`.
- Added helper function `chordcounter_model` in `helpers.py` to return the active `ChordCounter` model.
- Updated import statements in `database.py` to use `chordcounter_model` helper function.
- Added `ChordCounterModel` attribute to `DatabaseBackend` class, and updated `create` and `get` methods to use `ChordCounterModel` instead of `ChordCounter`.

Relates to: celery#305

for more information, see https://pre-commit.ci

for more information, see https://pre-commit.ci

….py'

…and multi-line output

This commit addresses an issue where the pre-commit hook merges import formatted with isort's multiline output mode 3 back into a single line, resulting in a flake8 E508 violation in CI due to lines exceeding 79 characters