Closes#1235
This commit introduce a pretty big change on how app data files are
managed. Instead of having multiple `accounts.json`, `settings.json`,
`user.json`, `countervalues.json`, it now store everything in a single
`app.json`. And it does it in an *async* way, so it should prevent some
frame loss.
Migration will be seamless, and will keep `accounts.json` encryption if set.
So no user action is involved.
This changes comes also with some simplification on password handling
(e.g: no more need to store password hash).
/!\ Disclaimer
During development, I ran about a weird issue (~ 3 or 4 times) when my
data was simply "erased" in the file, so back to onboarding, no more settings,
etc. I suspect race/write condition, something with write-file-atomic, but I
didn't managed to reproduce, everytime I tried. Anyway, I feel not 100% confident
with it, so if you guys can test on your side, with your data (with encryption
key or not) it will help a lot!
- Two components: <Track> and <TrackPage>. we should try to ALWAYS use them. only case you might not use them is for imperative events (click, etc..)
- also: introduce a "Use system locale" for the language because analytics need to diffferenciate if lang was set by user of fallbacked. it's also better when we'll introduce new lang to users to directly auto switch to their system's
- started to track some pages and events. there will be more required and we'll have to add some in the next days
Outdated rarely happen: it's only if you have not yet pulled for a time and you had no network condition. because otherwise, our pull interval is always smaller than the time we consider 'outdated' (set at block time + 5mn to be safe)
In case an error occur during the sync, we won't show it until one of the account is also outdated, which i think will lighten a bit the cases we have errors. we can decide later to be smarter and more verbose (like being able to know which account have a problem, which one is not sync etc..) but we'll need to have a design for it