WIP: add support for xBridge 2 with queue

[savek-cc]

@tzachi-dar

[tzachi-dar]

This part seems fine. We will not have duplicate packets.

As was discussed off line, There is still a lot to do (actually the more I look at it, the more to do...)

Looking more deeply at code: BgReading create() is working on current-sensor(). Current sensor might not be relevant.

Current calibration might not be the correct calibration.

Than bgReading.perform_calculations() might be called. In this function we call find_new_curve(). find_new_curve() is looking at List<BgReading> last_3 = BgReading.latest(3); which has nothing to do with the bg just created.

More than that: find_new_raw_curve() is also called and is also working on latest 3 points. find_slope() is working on more points.

Back to BgReading create() - there is code that is being executed after: if(calibration.check_in) { this is not relevant any more here. } else { code that is dealing with last bg reading. }

From there, code is calling BgSendQueue.handleNewBgReading() This opens call to many other services that also don't seem to handle random packets(). For example see wear_sync: looks at latest data. (List<BgReading> graph_bgs = BgReading.latestForGraph(60, startTime);)

My bottom line: I don't think that issues can be fixed in a reasonable time, I also don't think that there is a good reason to do that. In other words here is something that will work and solve 90% of issues:

1. Only accept packets on the order that they were captured.
2. Only accept packets for the latest calibration.

This is what wifi-wixel is doing to solve gaps, and is 100% fine for anyone that has only one xBridge in their system (99.9% of xDrip users, at least from what I know).

[savek-cc]

Will work as long as no one tampers with the system time - but since that would already be the case with the existing code (tampering with the clock to get values out of order) it should be fine. So basically the dupe check could be modified to make sure that the timestamp reading from a "fresh" transmission it greater than that of the last reading and the last bg. And since you should not be able to enter a calibration if you don't have a current bg value/transmitterdata, doing the check for transmitterdata should be sufficient.

[tzachi-dar]

This seems fine to me.