amari.kpi: Rework LogMeasure to prepare Measurement incrementally
We added LogMeasure in 71087f67 (amari.kpi: New package with driver for Amarisoft LTE stack to retrieve KPI-related measurements from logs) and its original logic is to read `stats` messages and to create Measurement that covers [Sx, Sx+1) only after seeing Sx+1. However in the next patch we will need to also take into account other smaller messages besides stats, and for that messages we need being-prepared Measurement to already exist to be able to amend it with partial data we see. So we need to rework the process to create Measurement that will cover [Sx, Sx+1) right after seeing Sx without waiting for Sx+1 to come in. This patch does that. Along the way it unifies how events and stats are handled. Previously events and stats were handled via different objects and the code had many scattered places that tried to handle cases like event-event, event-stats, stats-event and stats-stats. And for all those cases the intent was that we still want to emit corresponding Measurement for all of them, even if maybe if all NA data besides timestamps. Thus it does not make sense to split events and stats into different flows - as we can handle all combinations by considering just one flow of "stats or events". This simplifies logic and removes several sporadic branches of code to emit M(ø) around events. It also discovers several places where we were not emitting such M(ø) even though the intent was to do so. All this is fixed now with updated tests.
Showing
Please register or sign in to comment