rationalize processing by boot session

[jbrzusto]

Due to both receiver software bugs and jbrzusto/sensorgnome#53, the boot count embedded in SG filenames is not always a non-decreasing function of timestamp; i.e. bootcounts can jump backward from earlier to later files, e.g. due to reformatting an SD card.

Tag finder should take this into account. Options:

• fix embedded boot numbers in filenames post hoc, with notes from users
• calculate monoBN from bootnum, date information; this was the original idea behind the monoBN field: a monotonic boot number
• defer to file timestamps when running by existing bootnum.

The main problem in any of these cases is dealing with pre-GPS timestamps where the bootnum cannot be trusted. In most cases, such files will have a tail with records having accurate timestamps, which will allow us to place them in the correct (monotonic) boot session.

[jbrzusto]

• partial fix is to fill in the body for ensureMonoBN
• still need to decide if/when to run it

[jbrzusto]

ensureMonoBN still not working:

> ensureMonoBN(getRecvSrc("SG-2712BB000055"),testOnly=TRUE)
[1] TRUE
> ensureMonoBN(getRecvSrc("SG-2712BB000055"))
[1] TRUE
There were 46 warnings (use warnings() to see them)
> ensureMonoBN(getRecvSrc("SG-2712BB000055"),testOnly=TRUE)
[1] TRUE

After the second run, with testOnly=FALSE (the default), there should no longer be any time/bootnum inversions. But the 2nd run with testOnly=TRUE shows there still are.

[jbrzusto]

The check with testOnly=TRUE was the problem: it was using the uncorrected bootnum, instead of the corrected monoBN.