Inacurate start_index for reports originated from iOS app

[duskoo]

Logic in TcnKeys::create_report calculates start_index assuming that new tcn is generated every 15 min. This is correct for Android implementation.
iOS implementation, on the other hand, generates tcns on each read request (which occurs randomly), making the start_index inaccurate.

We need a way to correlate the number of iOS tcn generations to elapsed time: how many generations has occurred in 14 days preceding the infection report?

[ivnsch]

Additionally (as mentioned here), iOS sends a read request when the device UUID isn't cached. The lifetime of this UUID is unclear (at least per official docs). It may be long lived, up to the point of identifying a particular app installation.

[ivnsch]

Thinking more about this, TCNs being long lived for a particular observer doesn't seem to be a problem. The problematic part seems rather when they change too quickly (e.g. user goes to mass gatherings and "consumes" the TCNs for the infection period in a couple of days, pushing the older ones out, so e.g. a contact I saw 2 weeks ago will not be matched anymore). We can improve this by increasing the infection "period" to a sufficiently large interval?