fix(acquisition): pipeline performances

[jonathanfallon]

1. Problème de blocage du pipeline lié au lock sur la db

La table carpool.incentives a une contrainte de type foreign key sur acquisition.acquisitions._id. Lorsque l'on fait un FOR UPDATE SKIP LOCKED lors de la sélection des trajets à importer, la table carpool.incentives hérite du lock.
Actuellement le timeout permet de le faire sauter au bout d'un certain temps mais c'est la seule action qui le libère.

Lors de l'import des acquisition.acquisitions dans carpool.carpools et carpool.incentives, les étapes pour chaque trajet sont :

• normalisation géo, routes, coûts (providers asynchrones uniquement)
• création des carpools et incentives dans la base

La solution apportée est de supprimer la contrainte en base de données, ce qui a du sens car acquisition et carpool sont des services différents et il n'y a pas de raisons d'avoir des contraintes fortes entre 2 services qui doivent être indépendants l'un de l'autre.

2. Problème de gestion du timeout de secours pour le batch d'import

Pour éviter d'avoir des dead locks qui bloquent des trajets en base pour toujours, un timeout est programmé pour effectuer le commit de la transaction automatiquement.
La corrélation du problème précédent et une gestion du timeout à l'intérieur de la boucle ne fonctionnait pas correctement, même si elle arrêtait la transaction au bout d'une minute.
La gestion du timeout est réécrite. Il est reset à chaque nouvel import et reprogrammé pour s’exécuter 10s après. Si l'import d'un trajet est trop long, le commit est exécuté.
Un mécanisme de bypass permet de ne pas exécuter le dernier timeout si tous les trajets sont importés correctement (le dernier commit est bon)

3. Ralentissement des requêtes à OSRM (http) après la seconde requête

La configuration d'un agent http/https avec un { keepAlive: false } permet de clore la connexion dès la fin de la requête et de passer à la suivante plus rapidement. On passe de 2300ms à 140ms environ.