[axe] Utilisation du cache dans le service de gestion des alarmes

Le cache d'alarmes ne fonctionne pas (cf. #126 (moved)).

Corriger le cache introduira un autre bug : GetOneByEntityID part du principe que l'alarme présente en cache est forcément en cours, alors que GetLastAlarm met la dernière alarme (en cours ou non) de chaque entité en cache. Dans ces conditions, envoyer un événement check sur une entité n'ayant pas d'alarme en cours modifie l'état de la dernière alarme, qui est résolue.

Pour avoir des performances acceptables, il faut que GetLastAlarm et GetOneByEntityID n'aient en général pas besoin de faire de requête Mongo. Pour cela, je propose de garder le comportement de GetLastAlarm, et d'adapter les autres méthodes :

• GetOneByEntityID : actuellement il est possible que cette méthode renvoie une alarme qui est résolue. Il faudrait éviter cela :
  • si la récupération de l'alarme dans redis a réussi, il faut vérifier que cette alarme est toujours en cours avant de la renvoyer.
  • si la récupération de l'alarme dans MongoDB ne renvoie rien, il ne faut pas supprimer la valeur présente dans le cache (pour que cette valeur soit toujours lisible par GetLastAlarm).
• ResolveAlarms, ResolveCancels, ResolveSnoozes, ResolveDone et UpdateFlappingAlarms suppriment les alarmes résolues du cache. Il faudrait éviter cela :
  • il faut remplacer les appels à s.cache.Drop par s.cache.Set (pour mettre à jour l'alarme en cache). Si on fait juste ça il y a aura beaucoup de duplication de code. Je pense qu'il faudrait ajouter une méthode MassUpdateWithEntity (analogue à MassUpdate) au service d'alarmes.