[feature] support stats for timespans including a boot

[asksven]

The problem is indeed related to the fact that BBS does passive monitoring and uses snapshots. Each snapshot (reference) describes the stats of the stats at a given point in time, in terms of counters (e.g. alarms), volumes (network) and times (plus combinations). All those counters are based on userland / kernel counters that do not have any history and are reset at boot.

Now imagine following situation (over simplified):

ref "since unplugged": time = 12:00 alarms a1=500 wakeups, deep sleep = 10 minutes

reading at 12:30: time = 12:30 alarms a1=510 wakeups, deep sleep = 11 minutes -> since unplugged: time=00:30, alarms a1=10, deep sleep = 1 minute

I guess you get the picture.

Now happens a reboot, and all counters are reset to 0. Keeping the previous refs (I could just remove the handling at "on boot").

reading at 13:00: time = 13:00 alarms a1=12 wakeups, deep sleep = 1 minutes -> since unplugged: time=00:30, alarms a1=-488, deep sleep = -9 minute

I guess you get the picture...

What would be needed to support stats with boot in between would be:

1. a ref stored just before the reboot
2. a logic knowing that "since unplugged" is not just "current" - "since unplugged" but "current" - "since boot" + "at reboot" - "since unplugged"

Pretty tricky heh? Now add that there are many ways to reboot and not all will be proccessed by ACTION_SHUTDOWN (e.g. removing the battery) so sometimes there will be a continuity in the stats sometimes not.

Now that said I am willing to consider that as a feature and think of a logic to implement that continuity but I hope you understand that it's a little more than just commenting out the deletion of the references at boot.

[Tungstwenty]

For the "bad reboots" (if/when you go ahead with this) the obvious suggestion is to mark somewhere that a valid "before_reboot" ref was stored and if upon boot it doesn't exist, invalidate the refs that needed it (such as since_unplugged, since_charged) and fallback to the current behavior.

BTW this possible enhancement has synergies with #223