Detect the "zombie" jobs, and kill them 🧟 🔫
Sometimes the pods crash:

```
prod-datasets-server-worker-first-rows-8579994756-vgpkg           0/1     OutOfmemory              0               92m
prod-datasets-server-worker-first-rows-8579994756-vmvk7           0/1     OutOfmemory              0               92m
prod-datasets-server-worker-first-rows-8579994756-vsmmt           1/1     Running                  0               4h27m
prod-datasets-server-worker-first-rows-8579994756-vxtwn           0/1     OutOfmemory              0               3h12m
prod-datasets-server-worker-first-rows-8579994756-vzs6j           0/1     OutOfmemory              0               3h12m
prod-datasets-server-worker-first-rows-8579994756-w2k55           1/1     Running                  2 (3h25m ago)   4h16m
prod-datasets-server-worker-first-rows-8579994756-w5c6m           1/1     Running                  0               4h27m
prod-datasets-server-worker-first-rows-8579994756-w5ks6           1/1     Running                  1 (4h21m ago)   4h27m
prod-datasets-server-worker-first-rows-8579994756-w7ds5           1/1     Running                  0               4h27m
prod-datasets-server-worker-first-rows-8579994756-wbqlq           1/1     Running                  0               4h16m
```

The job that was running then stays forever in the "started" status, what we can call a zombie.

The issue is that, for the rules implemented in the queue logic, it can prevent other jobs for the same dataset, or for the same user, to be processed. It even prevents to re-run the same job.

Ideally, we should detect that the job has failed, change its status to "error" and put an error response in the cache database.

To implement this, an option proposed by @XciD is:
- to have a parallel thread (heartbeat) that will update the job in the database every xxx seconds
- a "garbage collector" loop will look for zombies and finish them as described above

Detect the "zombie" jobs, and kill them 🧟 🔫: Sometimes the pods crash:

```
prod-datasets-server-worker-first-rows-8579994756-vgpkg           0/1     OutOfmemory              0               92m
prod-datasets-server-worker-first-rows-8579994756-vmvk7           0/1     OutOfmemory              0               92m
prod-datasets-server-worker-first-rows-8579994756-vsmmt           1/1     Running                  0               4h27m
prod-datasets-server-worker-first-rows-8579994756-vxtwn           0/1     OutOfmemory              0               3h12m
prod-datasets-server-worker-first-rows-8579994756-vzs6j           0/1     OutOfmemory              0               3h12m
prod-datasets-server-worker-first-rows-8579994756-w2k55           1/1     Running                  2 (3h25m ago)   4h16m
prod-datasets-server-worker-first-rows-8579994756-w5c6m           1/1     Running                  0               4h27m
prod-datasets-server-worker-first-rows-8579994756-w5ks6           1/1     Running                  1 (4h21m ago)   4h27m
prod-datasets-server-worker-first-rows-8579994756-w7ds5           1/1     Running                  0               4h27m
prod-datasets-server-worker-first-rows-8579994756-wbqlq           1/1     Running                  0               4h16m
```

The job that was running then stays forever in the "started" status, what we can call a zombie.

The issue is that, for the rules implemented in the queue logic, it can prevent other jobs for the same dataset, or for the same user, to be processed. It even prevents to re-run the same job.

Ideally, we should detect that the job has failed, change its status to "error" and put an error response in the cache database.

To implement this, an option proposed by @XciD is:
- to have a parallel thread (heartbeat) that will update the job in the database every xxx seconds
- a "garbage collector" loop will look for zombies and finish them as described above
