Fix handling of comms error on resume & all pod DeliveryStatus cases

[marionbarker]

This PR uses code changes from @itsmojo to address Trio Issue 244: Critical Pod Fault 049 (0x31) Error When Resuming Insulin Delivery

See also Loop Issue 2121: Bug Report: Eros Pod Fault of 0x31 (-049), specifically this comment

[marionbarker]

I'm not sure how to reproduce the failure.

I built the improved_delivery_status branch (from this PR) onto a test phone with an rPi simulator. Both the Loop and Trio versions behaved nominally for 24 hours.

I have now installed this version on my real Loop phone with a DASH pod. I will continue to monitor the behavior.

[dnzxy]

This LGTM and should be good to go.

Side note: All these vars that handle the various cases within checks and return a boolean value could be rewritten to be a bit more readable with essentially the same time complexity (O(1) for both, with one-time cost of O(n) for creating these Sets) and identical functionality.

Example:

// current implementation
 public var bolusing: Bool {
        return self == .bolusInProgress || self == .bolusAndTempBasal || self == .extendedBolusRunning || self == .extendedBolusAndTempBasal || self == .priming || self == .extendedBolusWhileSuspended
    }

// suggestion
public var bolusing: Bool {
    let bolusingStates: Set<DeliveryStatus> = [
        .bolusInProgress,
        .bolusAndTempBasal,
        .extendedBolusRunning,
        .extendedBolusAndTempBasal,
        .priming,
        .extendedBolusWhileSuspended
    ]
    return bolusingStates.contains(self)
}

However, this totally is personal preference and not necessary. PR is 100% good as-is.

[marionbarker]

While testing another feature in Trio, Trio got into a state where it thought the rPI DASH had resumed delivery when it was still suspended. This was using the dev branch of OmniBLE (commit 91abd9a).

See details below.

See nightscout/Trio#277 (comment) for the testing associated with this circumstance: Repeat the information here:

OmniBLE Test for OmniBLE PR 125

While running the DASH testing for Trio to first suspend and then resume:

• got into a state where pod state of rPi does not match what Trio thinks
• time stamp is just before 13:00 PDT
  • reading the HEX from the rPi simulator: hx="1724b075240a1d08001f100000000fff0000"
  • extended_bolus_active = False, immediate_bolus_active = False, temp_basal_active = False, basal_active = False
  • but Trio thinks pod resumed successfully and is running scheduled basal of 0.7 U/hr
  • The only allowed button to push on Trio was to Suspend delivery - except it was already suspended.
  • modify the OmniBLE submodule to point at improved_delivery_status branch for OmniBLE
  • rebuild the app between 2024-06-07 12:56:53 and 2024-06-07 12:59:55
  • Using the new version of OmniBLE, Trio reports insulin is suspended - this is correct! (Add this log to OmniBLE PR 123 as proof this fix works)
  • upload the log file and csv file
  • This demonstrates that the code modified by this PR worked as expected.

That tests involved some Medtronic tests as well as DASH. Shorten the log file to be just the pod portion, then parse the file:

• log_pod_only.txt
• podState_Marion_Simulator_Trio_20240607_1.csv

[marionbarker]

Thank you for your review and your proposed more readable method for the boolean statements.
I'm going to delay that for now. The code as written has been tested and works.

In the future, if we ever combine the code for OmniBLE and OmniKit into a single sub-module, improvements like this will certainly be considered.