Allow fallback from online to offline scan

[raphaelm]

A large customer wished for better timeout handling of scans if the network goes down. They already use our "automatically switch to offline mode after multiple slow scans" feature, but they don't want to wait the full 30s timeout for multiple scans before they switch to offline.

This PR therefore introduces a fallback option for scans. In other words, if the automatical decision between online and offline mode is enabled, the app can now also change its mind after the scan started, i.e. we first try if we can process it online and after a short timeout, we switch to a offline scan without actually requiring another scan.

Now, the following scenarios are relevant:

1. Our original scan attempt has never reached the server or has never been processed there. Therefore, our offline scan will be the only scan recorded. This is acceptable, since it's not worse than if the scanner would have auto-switched to offline mode a minute ago.

2. Our original scan attempt has been processed on the server but we never received the response. The outcome depends on the processing result:

   a) The scan was successful both on the server as well as with our fallback method. Everything is fine. Since both scans carry the same "nonce", only one scan will be in the database since the server ignores our upload of the offline scan later.

   b) The scan failed on the server as well as with our fallback method: Everything is fine. Since both scans carry the same "nonce", only one scan will be in the database since the server ignores our upload of the offline scan later.

   c) The scan failed on the server, but our fallback method recorded a successful scan: This is not great, because someone got in who shouldn't have, but it's no worse than if the scanner would have auto-switched to offline mode a minute ago, so it's acceptable by any user who configured our app like this. The database will later show both a failed and a successful scan (since nonces of failed scans do not block further scans), but that's also the most sensible description of what happened to a user who looks at the process in the backend, so we consider it acceptable. It's also no different to a user manually quickly retrying the scan after a failure.

   d) The scan succeeded on the server, but failed with our fallback method. This is the worst situation since a valid scan is recorded and the ticket is now marked as used, even though the ticket holder did not get in. This risk always existed as it can happen in any situation where the request reached the server but the response did not reach the scanner, but it becomes a more likely situation with a lower timeout. Maybe that's just a risk that needs to be accepted by anyone using this feature? I'm not too concerned since usually the offline mode is usually more likely to return a successful scan than the online mode (e.g. with signature-based scanning). We could implement this differently through a server-side mechanism that deletes the successful scan later, when the app uploads a failed scan with the same nonce. I'm not sure whether we should, though, because Checkin records on the server are currently kinda immutable and hence audit-proof. Introducing a mechanism that removes successful checkins after the fact sounds like a big risk as well.

Dependent PR: pretix/pretixscan-android#71

Required PR: pretix/pretix#3516

[codecov]

Codecov Report

Patch coverage: 22.78% and project coverage change: -0.31% ⚠️

Comparison is base (fa0e282) 24.83% compared to head (7d87414) 24.53%.

Additional details and impacted files

@@             Coverage Diff              @@
##             master      #29      +/-   ##
============================================
- Coverage     24.83%   24.53%   -0.31%     
  Complexity      383      383              
============================================
  Files           104      105       +1     
  Lines          5620     5706      +86     
  Branches        994     1002       +8     
============================================
+ Hits           1396     1400       +4     
- Misses         4005     4084      +79     
- Partials        219      222       +3     

Files Changed	Coverage Δ
...main/java/eu/pretix/libpretixsync/api/PretixApi.kt	7.23% <0.00%> (-0.68%)	⬇️
.../pretix/libpretixsync/api/TimeoutApiException.java	0.00% <0.00%> (ø)
.../pretix/libpretixsync/check/OnlineCheckProvider.kt	0.00% <0.00%> (ø)
...u/pretix/libpretixsync/check/ProxyCheckProvider.kt	0.00% <0.00%> (ø)
...java/eu/pretix/libpretixsync/sync/SyncManager.java	0.00% <0.00%> (ø)
...u/pretix/libpretixsync/check/AsyncCheckProvider.kt	63.35% <52.54%> (-0.71%)	⬇️
.../pretix/libpretixsync/check/TicketCheckProvider.kt	58.02% <83.33%> (+0.88%)	⬆️

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.