VxScan: implement WAL to recover from ill-timed crashes

[benadida]

Summary

If our system crashes, for any reason, right after accepting a ballot but before storing said ballot's CVR, we are going to be off by 1. This crash is unlikely and never yet observed, plus the tablet has a battery so even kicking the power cord isn't going to trigger it, and the problem window is very small, but still, we should be perfectly resilient to this.

The likely implementation is logging the CVR to disk before the plustek accepts, with a flag indicating that the CVR is not yet accepted. Then on restart, based on where paper is present, we can make a decision as to what to do. If there's no paper out the back, then it was already accepted, we can mark the CVR as accepted. If there is paper out the back, we can actually accept it, and then update the CVR normally.

[carolinemodic]

@benadida are you worried about this for MVCP?

[adghayes]

@arsalansufi is @benadida's concern above still relevant?

[arsalansufi]

@adghayes This concern is still theoretically relevant, as the state machine tells the scanner to accept the ballot and then writes to the DB right after that operation finishes. (Note that I'm not talking about the write to USB drive here but the write to disk. There are mechanisms in place to make sure that a write to disk always pairs with a write to the USB drive, but we're talking about an issue earlier in the pipeline here.)