Improve handling of saved app state

[philrz]

#2527 taught us a few important lessons about the current monolithic appState.json that's used to save all the persistent state between launches, e.g., window size/positioning, open tabs, query history, saved queries, preferences, and so forth.

1. Bugs may exist that effectively make for a corrupt appState.json (i.e., the app is not able to read it in the previously-saved state well enough to fully launch). We fixed the specific cause of #2527, but other similar bugs may be out there waiting for us, and some kind of blanket improvement to reduce their severity would be helpful.

2. The current UX from such corruption (i.e., the user double-clicks an icon to launch the app and nothing seems to happen) is bad. It leave them little choice than to engage directly with us to debug using via log messages, and the log messages produced may or may not point to an obvious root cause (e.g., we didn't fully understand #2527 until the user sent us their appState.json). Data sensitivity (e.g., contents of query history or saved queries) may prevent the user from being able to freely share their appState.json to help us debug.

3. Quick fixes to the problem such as effectively losing some/all of what's in appState.json (in the spirit of #2525, which was considered as a fix for #2527) will probably be bad for some users. If a user sees the app as a "scratch pad" where they rarely/never save queries or refer back to query history, starting from fresh state by losing appState.json would be seen as an improvement vs. silently failing to launch. But to a user that spent a lot of time crafting saved queries or referring back to important query history, this would be catastrophic.

We discussed this as a group and agreed that we could stand to improve here. Here's some of the ideas put on the table thus far.

• The monolithic appState.json could still be used, but the app could do more to back it up and make the user aware of its significance. For instance, I was reminded of the flow.xml.gz: in Apache Nifi (docs) of which a backup/archive copy is made as a side effect of autosave every time a user makes a change. Nifi's approach allows the user to roll back at any time by using an older copy. Perhaps we could adopt a similar approach and then catch conditions where the appState.json is seen as unusable at launch time, then move the unusable one off to the side and inform the user to contact us for support purposes, but otherwise launch with the prior saved version.

• @jameskerr correctly pointed out that the data we currently persist in appState.json is not all of equal value. For instance, things like window size/positioning would probably not be catastrophic to lose, whereas saved queries and history might be quite valuable. We could start saving these things in separate files or mini SQLite DBs, which would reduce the scope of data loss from corruption in any one area.

• The team noted that Chrome (on which Electron is based) might have existing mechanisms for managing such saved configs, so we might want to leverage those.

[jameskerr]

Thanks for documenting all of this Phil