Modified job add or update mechanism

[antoineludeau]

I. Context

In order to transfert data from postgres to mongo, we send a job to the 'export-to-exploitation-db' worker queue. This job is delayed (30s) so that multiple incoming requests (put/post/delete) during the period of delay are gathered in one export for the concerned district.
For example, id-fix is making a lot of api call during a short period of time. We don't want each call to result in an export to mongo.

The first mechanism in place was to send a job to that queue with an ID corresponding to the districtID. Each time we want to add a job we were checking if the job (with the same ID) was already in the queue and if it was the case, we were trying to remove it and replace it by a new one (with the same delay).

The issue with the first mechanism was that, once the job was active (= in processing by the worker), we could not stop it and delete it. And we couldn't add a new job to the queue as there were sharing the same ID.

II. Enhancement

This PR aims to modify this first mechanism :

• We now add a job not with a specific ID (we let 'bull' adding a unique ID on itself)
• Each time we want to add a new job, we first checks the jobs that are in the "waiting" or "delayed" queue (for more information about bull lifecycle : https://optimalbits.github.io/bull/). We check if the job data has the same districtID. If it is the case, we don't add a new job. If not, it means either the job is 'active' or there is no job at all : as a consequence, we add it to the queue.