[Payments] Reader software update improvements

[iamgabrielma]

While these issues were found during testing the Stripe update to 3.x, we also have experienced these issues before the update, so it should be unrelated to the recent SDK update.

From review: https://github.com/woocommerce/woocommerce-ios/pull/11080#issuecomment-1814122357

Connecting to a Chipper reader which needed an updated never showed the update, completed, nor timed out: app ended up in a locked-up state and had to be force-quit. A subsequent attempt worked correctly though. No cancel button or logs, so I'm not hugely concerned... but might be worth a look.

From review: https://github.com/woocommerce/woocommerce-ios/pull/11080#issuecomment-1814178998

After doing a mandatory update of a WisePad 3, the reader connected with up to date software, but the software update screen never showed its dismiss button. IIRC there's some slightly hacky code around showing that button, which may be relying on some old assumptions. This was a required update.

From testing: pfoUAQ-eW-p2#comment-146

When a card reader is not charged above 50, and an update is needed, then we show an explanation pop-up that says to charge a reader. But for some reason, when a user clicks on “ok” we don’t finish the flow but continue “scanning” for a reader.

[iamgabrielma]

Some debugging, and understanding/questions to clarify:

• Optional updates can be cancelled
• Mandatory updates cannot be cancelled, hence, we do not render a cancel button for those
• The "software update" modal should be dismissed automatically once the update is done

The current logic on CardPresentModalUpdateProgress indicates that the secondary button (cancel action) will render if cancellation is not nil (so an update is cancelable, not mandatory), otherwise, render nothing. This will happen as long as the update is not complete:

actionsMode = cancel != nil ? .secondaryOnlyAction : .none
... 
if !isComplete {
  messageInProgress = requiredUpdate ? Localization.messageRequired : Localization.messageOptional
}

An alternative could be to:

1. Extract this logic into a clearer method, passing the specific SoftwareUpdateTypeProperty type.
2. Always offer a cancellation/completion button after the update is complete, not relying only on automatic dismissal upon completion.

By forcing a fake update we can see how we could switch state for different buttons based on completion, then the merchant could tap to finish the flow if needed: