A restarted task should have the same identity as far as the client is concerned

[jonboiser]

Observed behavior

• Add /api/tasks/restarttask endpoint #7905 Implemented a API endpoint to restart tasks with only the canceled or failed task's ID.
• When a task is restarted, a new job is enqueued that has the same parameters of the old one. So it is "identical" in all respects except the job's ID.
• When the client polls /api/tasks/tasks, after the task is restarted. Task with the original ID disappears, and the new one appears.
• Because the client uses the task ID to manage the Task Manager card with the task progress, this results in the old task disappearing and being replaced by the new one, etc.

See Video in #7905 (comment)

Expected behavior

When the client requests /api/tasks/tasks after the task is restarted, the restarted task remains in the response payload, but just has its status updated.

Ideally, the result on the UI will be that, after the task is restarted, the Task in the Task Manager will simply go from a canceled/failed state to a running state, without having to disappear/reappear.

Technical notes

This can probably be done by replacing this line

https://github.com/learningequality/kolibri/blob/develop/kolibri/core/tasks/queue.py#L80

With job.job_id = job_id.

[vkWeb]

@apurva-modi would you mind if I attempt at solving this issue? 😅

Because I want to understand the task api as I plan to work on it in gsoc so this will give me a hands-on chance to explore and understand the task api.

@jonboiser if for some reason the issue assignment cannot change then can you suggest me some issues that require work on task api? :)

[jonboiser]

@vkWeb Feel free to explore the Task API. If you end up fixing this issue, as well as the tests related to it, I'd be happy to look at your PR.

This other issue (re: tasks losing their metadata after the server is restarted) is also a good issue that you can focus on. #6255

[vkWeb]

@jonboiser hey, thanks for the chance! Okay - I've started my work on this one. Once I properly fix this then I'll move on to #6255.