Monitor ENF calculation more closely for better progress feedback (EXPOSUREAPP-2743)

[d4rken]

Why

We want to display better progress feedback, we want to know when the download is happening and when we are waiting for the ENF to check the keys.

The goal is to show two different progress types, this PR does not yet add that, but adds the necessary base classes. For now the isRefreshing state will be displayed on the risk card if either the transaction is on-going, or the ENF is still calculating.

How

This PR adds the CalculationTracker, which is a set of classes that can track the ENF calcluations that happen outside of our app process.
The idea is:

• Every time we submit submit key files to the ENF, we store an identifier (the token we also pass to the ENF).
• Register for both ACTION_EXPOSURE_STATE_UPDATED and ACTION_EXPOSURE_NOT_FOUND
• When we receive a broadcast for either action, the token is included returned to us by the ENF and we mark the respective entry as finished.

To the rest of the app we expose a CalculationTracker.calculations: Flow<Map<String, Calculation>>:

• We store the last 5 started calculations.
• If any of those does not have a finishedAt timestamp set by us, it's still calculating.
• We consider the calculation still in progress as long as there is at least one unfinished calculation.
• The data should be accessed via ENFClient which offers easier access with
  • isCurrentlyCalculating(): Flow<Boolean>
  • latestFinishedCalculation(): Flow<Calculation?>

To notice any issues within the ENF that don't throw us an exception, there is a timeout checker running within the calculation tracker.
Every 5 minutes it will evaluate the startedAt timestamps of all known calculations. If it exceeds the timeout (currently 60 minutes, @mlenkeit thoughts on that?, might be a bit high), the calculation is considered "timed out", get the result type "TIMEOUT", and given the current time as finishedAt timestamp (which marks it as no longer "in calculation").

The calculation data is persisted everytime there is an update to the data map. The class CalculationTrackerStorage loads and stores the map as serialized JSON file to our private app storage.

Testing

• Observe the log for CalculationTracker
• Start risk level calculations and observe the log and the progress state of the risk cards.

[d4rken]

In another PR we should consider replacing the timestamp on the risk card, which currently reflects the last time the download was finished, but it makes more sense if it's the timestamp of the newest tracked calculation (which would IMHO be the fix for #948).

[d4rken]

This PR also introduces a nice helper class dubbed HotDataFlow.

It's a flowable that

• Does lazy init. The start value is provided via a suspending function that is only executed if someone subscribes
• Shares all updates between all subscribers as long as there is at least one subscriber.
• Allows threadsafe updates to it's contents as it only allows its data to be changed by giving it an "update function" that takes the current value and can return a new one.

[ralfgehrer]

Turned out very nicely.

[d4rken]

I've changed the ENF.isCalculating to only check the state of the newest submission. With batched submission there is only a small chance for overlapping calculations and it reduces the chance that we actually run into a timeout and the user sees a prolonged "progress" state. As we currently submit all key files each time, each new calculation would superseed the previous anyways.

[vaubaehn]

You invited for feedback. First class. Nothing else to say. 👍

[mlenkeit]

@d4rken as discussed, let's set the timeout to 15 minutes initially, should already be quite conservative.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities (and 0 Security Hotspots to review)
0 Code Smells

71.4% Coverage
0.0% Duplication

[BMItr]

passed deep look & test. lgtm