✨ Long running tasks: allow retrieving tasks by user

[sanderegg]

What do these changes do?

This is a pre-requisite so that the frontend may retrieve currently running project copy tasks after a refresh or a snap (will need @odeimaiz to modify the frontend accordingly).

long running tasks framework:

• implementation of listing of tasks (aiohttp/fastapi)
• modified all tasks routes to take care of the "task context" (like a user_id), only in aiohttp
• a task context can be defined (such as in the webserver something like {user_id: 123, product: osparc}, then every task route will filter with that task context (e.g. user 1 cannot see the tasks of user 3, user 1 can only cancel his/her own tasks)
• simplified and refactored testing (both aiohttp/fastapi)

webserver

• adds GET /tasks in the webserver REST API, which returns the list of currently running async tasks in the webserver for a specific user_id (through the usual logged in user facility): return the list of tasks of the user in the form of POST /v0/projects?from_study=de2578c5-431e-6257-a462-d7bf73b76c0c
• added test to check that one user cannot access another user tasks
• allow setting a task name so the frontend may retrieve the user tasks (task name is set as "METHOD path")

Related issue/s

related to ITISFoundation/osparc-issues#428

How to test

cd packages/service-lib
make "install-dev[all]"
make "test-dev[all]"

cd services/web/server
make install-dev
clear && pytest -vvx --pdb --color=yes --asyncio-mode=auto --ff --cov-config=../../../.coveragerc --cov-report=term-missing --cov=servicelib --keep-docker-up tests/unit/with_dbs/02/te

Checklist

[codecov]

Codecov Report

Merging #3268 (b3939e8) into master (38b6073) will increase coverage by 1.0%.
The diff coverage is 94.9%.

@@           Coverage Diff            @@
##           master   #3268     +/-   ##
========================================
+ Coverage    82.3%   83.3%   +1.0%     
========================================
  Files         755     682     -73     
  Lines       32249   30025   -2224     
  Branches     4121    3829    -292     
========================================
- Hits        26549   25028   -1521     
+ Misses       4859    4214    -645     
+ Partials      841     783     -58     

Flag	Coverage Δ
integrationtests	66.3% <75.0%> (+<0.1%)	⬆️
unittests	79.5% <94.9%> (+0.7%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...namic_sidecar/api/containers_long_running_tasks.py	100.0% <ø> (ø)
...rvice_webserver/projects/projects_handlers_crud.py	87.4% <75.0%> (-0.8%)	⬇️
...vice_dynamic_sidecar/modules/long_running_tasks.py	90.2% <100.0%> (ø)
...erver/src/simcore_service_webserver/application.py	98.8% <100.0%> (ø)
...rc/simcore_service_webserver/long_running_tasks.py	100.0% <100.0%> (ø)
...mcore_service_webserver/garbage_collector_utils.py	82.0% <0.0%> (-2.6%)	⬇️
...ector_v2/modules/dynamic_sidecar/scheduler/task.py	81.1% <0.0%> (-1.3%)	⬇️
.../director/src/simcore_service_director/producer.py	61.6% <0.0%> (-0.5%)	⬇️
...imcore_service_webserver/garbage_collector_core.py	71.0% <0.0%> (ø)
...ervicelib/aiohttp/long_running_tasks/_constants.py
... and 76 more

[pcrespov]

Very nice!
Some minor comments and thoughts below

[pcrespov]

STYLE: the word task might refer to different concepts. I suggest that we denote these as long_running_tasks or long_tasks or lgr_tasks ... or something similar.

[sanderegg]

is this not a bit exagerated? this lives in a module named long_running_tasks already. and everything in here talks about tasks. I do agree with that fact.
I will think of it for a different PR.
I could also think of renaming the module package into something like rest_async_task instead of long running... since what is long?

[pcrespov]

so here the lrtask context is decided to be exactly as the request context. Is it always the case?

THOUGHT:
if so, perhaps we need to store the request (storage) always instead of defining a new task_context...
AFAIK you want to keep track of the "original" request that triggered the lrtask, right?

[sanderegg]

ok, but how do I know what needs to be taken out of the request?

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

No Coverage information
0.0% Duplication