Add carb entry override warning

[billybooth]

Added support for presenting an appropriate warning cell via the CarbEntryViewController when an active override is modifying insulin needs. This safety risk mitigation was discussed in the #development > Safety Feature Requests topic on Zulip. I opted not to display this on the basis of an arbitrary effectiveInsulinNeedsScaleFactor +/-, but instead display the warning if the effectiveInsulinNeedsScaleFactor modifies insulin needs at all.

As @ps2 suggested in the Zulip chat, optional UITableView rows are a bit tricky, so although an effort was made to properly support distinct warning row types (and allow for more to be added), additional refactor would be required to support more than two types of warning rows.

fileprivate enum WarningRow: Int, CaseIterable {
    case carbEntry
    case override
}

Here is a screen grab of the newly introduced override warning row:

And naturally, support is present for stacking both the override and carb accuracy warning rows:

Below is a reasonably full demonstration of the behavior added:
https://user-images.githubusercontent.com/20958170/211216471-8e4932f9-91b5-4c47-a890-84b61c00f27d.MOV

The changes here have been extensively tested and I have a lot of confidence in them, but due to critical importance of this view/view controller and the hazardous nature of dynamically manipulating the UITableView rows, I think this merits a rather thorough review by @ps2.

Let me know about any required changes or feel free to make them yourself if it's more expedient.

[billybooth]

Failed to notice associated feature request #1875. This PR at least partially mitigates the safety concerns raised there.

@marionbarker said:

Describe the solution you'd like
One solution is to alert users that an override is in effect when a carb entry is entered or edited.

[ps2]

Thanks! I like the wording on the warning. The logic is getting a bit tough to follow, and maybe a dynamic list (of sections and warning rows) approach would be simpler to read, but if you've tested this well, I think the approach is ok. At some point we should convert this to SwiftUI.

One edge case is making sure we don't generate any consistency violations (crashes) if the shouldDisplayOverrideEnabledWarning variable changes while on screen. This could happen if a remote override was enacted while the screen was displayed, for example. If you're not set up to enact remote overrides easily, maybe just adding a timer to change the option after a couple seconds would exercise that part of the code, and you could remove the timer after you're convinced it's working.

[marionbarker]

I tested this with remote override commands and reported in zulipchat: https://loop.zulipchat.com/#narrow/stream/144182-development/topic/Safety.20Feature.20Requests/near/320492954

[billybooth]

@ps2 said:

One edge case is making sure we don't generate any consistency violations (crashes) if the shouldDisplayOverrideEnabledWarning variable changes while on screen. This could happen if a remote override was enacted while the screen was displayed, for example. If you're not set up to enact remote overrides easily, maybe just adding a timer to change the option after a couple seconds would exercise that part of the code, and you could remove the timer after you're convinced it's working.

Sorry that the demo video doesn't appear to be rendering in conversation view; it plays back fine if you download it. Yes, as part of testing, I was flipping shouldDisplayAccurateCarbEntryWarning every other minute and turning overrides on and off with my watch to flip shouldDisplayOverrideEnabledWarning and force loop data updates. I am reasonably confident that no consistency violations can surface from these changes, but I apologize for the code not being super-readable. I tried to add comments where I thought they could be helpful, but it's clear that this would be a great candidate for migration to SwiftUI, since the effort required to accomplish this here is a bit much.

[ps2]

Oh, sorry I missed the video! Thanks.