G7 End of session detection bugfix

[ps2]

Attempt at fixing LoopKit/Loop#2286 (and maybe LoopKit/Loop#2278).

If a G7 sensor connects and disconnects without sending glucose data, Loop was interpreting this as an end of session trigger, and forgetting the old sensor id and starting to scan for a new one. It seems in recent iOS updates, sometimes Loop doesn't get the glucose reading during a connection session, which was triggering the end of session detection prematurely.

This PR changes how end of session is detected, using new algorithm state decoding, and still keeping the original check intact once the sensor lifetime + grace period has ended.

This PR still needs testing to ensure it's reliably detecting end of session for failed sensors, and early ended sensors, and auto scanning for the new sensor.

[marionbarker]

Tests

Initial test on "working" phone looks good.

Test on phone with no issues

I built this onto my personal Looping phone

• I have no history of missing G7 data with this phone

Configuration

• iPhone 15 pro running iOS 18.3.2, customized version of 3.4.4

Test Results

• Glucose continues to be displayed on main screen with this version of G7SensorKit
  • observe that values update over next 2 cycles
• quit the Dexcom app
• Remove CGM from Loop
• Add a G6 just to make sure G7 vestiges are removed, enter XXXXXX as transmitter ID, remove Share credentials from G6, wait for one more cycle
  • tapping on glucose took me to Dexcom G6 app (which is not running)
  • Delete G6 as CGM
• Add G7 back as CGM
  • Get "Searching for Sensor" icon
  • Restart the G7 app (it is stale, shows 102 from from 10:16, currently 10:25)
  • Updated value to 103 on G7 app, check Loop, it shows 103.

[motinis]

Hopefully this works - although if it does, it makes me think that in the scan-fix the backup handling for connecting of the sensor could have just relied on the SensorServiceUUID.cgmService.cbUUID and not the advertisementService as well (?).

[dnzxy]

@ps2 Could you please share some insights on the issue you have identified (for the two linked Loop issues) and how the proposed fix here is attempting to fix it. Just from the description alone, it is highlighting possible limitations of the proposed solution while not really going into detail what the identified, underlying problem seems to be or what the proposed solution aims to solve; the code change itself just shows that a guard is being extended by a time-based guarding component and more recently added logging.
Thank you.

[ps2]

@dnzxy The code checking for a connect/disconnect with no glucose reading was attempting to detect end-of-session, as that's what we see after a session end: the sensor continues to connect and disconnect, but no data is sent (probably because the g7 app is not asking for any). It seems that recently, perhaps due to iOS changes, sometimes we don't get the data during a connection period, and so this code was triggering prematurely.

So I've changed it to not trigger prematurely, but this means that we're left without a way to detect early end of session.

The recent commits to this PR are attempts at adding back automatic detection of early end of session due to manual ends or sensor errors, so we can start scanning for the new sensor proactively.