Fix data coming from DB integration about elescore HOT 3 CLOSED

First step is to detect when the API is disrupted. To do this it's possible to compare number of disrupted facilities and look for spikes. If first there are about 180 and suddenly there are 2200 disruptions it's a downtime. Similarly when it decreases to 0 from 180.

Once a disruption is detected, monitoring must continue until the disruption is resolved (disruptions are "around" 180 again). In this phase all events are filtered out and kept inside the monitor for later reference.

Then the last known good state and the current state must be compared. Occurred events will then be released based on the model below. It's currently not intended to generate new events on the fly so the actual ones that have been emitted must be used. If that is impossible, I need to re-think some parts.

MonitorP must implement the original idea from #4 :

<---> defines the time range in which the API is known to be disrupted.

|-------------------------|
|------------------------>| Case 1: Monitoring dis. only
|------------<----------->| Case 2: Disruption before, resolved after
|-----<------>------------| Case 3: Disruption before and after
|------------>------------| Case 4: Disrupted after

-> monitoring dis only = ignore
-> Case 2 -> we don't know when it really ended; have to include

from elescore.

To do this it's possible to compare number of disrupted facilities and look for spikes.

Easier said than done. The 1.5 x IQR rule turned out to be good enough.
Next up: Compensating actions.

from elescore.

Turned out that was quite easy using the already existing disruption monitor.

from elescore.