⚠️ chore: remove group from task args and move task user to datashare app

[ClemDoum]

⚠️ Requires Redis migrations (I'll do it)

Bug description

This PR aims at addressing some of the serialization issues/descrepencies between datashare.asynctasks and icij-worker.
More precisely, datashare.asynctasks systematically includes the task User and Group inside the Task.args.

However inside icij-worker all task arguments are forwared to task functions, ending up in python TypeError because of extra arguments (namely user and group).

The bug hides the 2 following issues.

datashare-app User concept leakage

datashare.asynctasks APIs use the User type which is a datashare-app concept. While this concept is used in the Datashare app, applications using a TM + workers won't necessarily use a User (which is a DS specific concept). In particular icij-worker as no knowledge of such concept, because most Python TM + worker applications won't use it. Basically, the User concept is leaking from datashare-app to all applications (including non Java application) following the datashare.asynctasks / icij-worker API.

Leaking the internal Group concept to task implementers

datashare.asynctasks serializes the group inside task arguments, which implies that task functions must be able to have a group argument as input. However task functions dont need the group argument to be performed. The Group is a datashare.asynctasks / icij-worker "internal". Task implementers shouldn't need to include the group argument inside their task function to make them work.

Fix

Chosen fixes

I chose to remove the User concept from datashare.asynctask and move it inside datashare-app, where task are created with a user argument, this only task performs for datashare will need to feature this argument. datashare-app uses a DatashareTaskManager extends TaskManager which includes all User related API (which were removed from TaskManager). Additionnaly, the DatashareTask helper class was implemented to create task with a user arg. I choose no to create a DatashareTask class inheriting Task because this breaks the task serialization ("@type": "DatashareTask").

I chose to align datashare.asynctasks behavior on the icij-worker one. Basically, when we create a task for the first time, we can assign a group to this task, hence, the TM has knowledge of the task group. The TM can keep track of task group rather than adding it to the task arguments.

Discarded fixes

A first solution I thought about was to implement Python fix to this issue by systematically removing the user and group arguments from the args received from the broker.
However I quickly discard this options because it basically "reserved" the group and user argument names for task implementers. These names are quite commons, and if we systematically remove them, it means that task implementers can't use them. An alternative solution whould have been to explore the Python task arguments and filter out all misnamed arguments, but I don't really like this approach as it can lead to silent failures.

Changes

⚠️ datashare-tasks

Changed

• updated the TaskManager API to keep track of the Group. Rather than always calling save to create and then update tasks, we now use saveMetadata to persist a task and it group (and potentially other persistent metadata) for the first time, then we call persisUpdate(Task<V> task) to update the task itself, other persistent metadata remain untouched (basically once a task is saved with a group information, there's no reason to update it). This behavior is similar to the icij-worker behavior, where the group information is not persisted in task themselve, be it's the TM's responsibility to keep track of it.

Removed

• remove all User related APIs

⚠️ datashare-app

Changed

• created a DatashareTaskManager and DatashareTask to implement user related task APIs