Turns out a lot of the typescript warnings about improper warnings were correct. TypeScript appears to be pulling in two copies of the js-sdk when we do this, which can lead to type conflicts (or worse: the wrong code entirely). We fix this at the webpack level by explicitly importing from `src`, but some alternative build structures have broken tests because of this - jest ends up pulling in the "wrong" js-sdk, breaking things.
This is needed because `require()` means something different in webpack - it ends up importing the module as something we didn't expect (and is occasionally async)
`createMatrixClient` and surrounding paths support an argument to disable
IndexedDB, but it is never actually used. This removes the option to simplify
the code.
The React SDK has a client creation path that starts 2 out of 3 stores, but then
leaves the other one for the JS SDK's default value handling.
We'll soon be adding additional code to check the health of stores, so it would
be simpler to follow and think about if we create them all in one place.
If we can't start indexeddb, fall back to a different store.
Previously we just ignored the exception and ploughed on anyway, on
the assumption that startup() was just for the indexeddb store to
load data anyway, and if that failed it would just do an initial
/sync instead (and also we'd keep trying to save the sync back which
would fail...). Then, in the previous release we started pulling
the settings out of the store on startup, making the assumpton that
the store actually worked, so the read obviously failed and the app
failed to start up.
This makes Riot work in Tor browser / firefox in daft mode again.
It turns out that Firefox doesn't let you use indexeddb from private tabs,
*unless* you are *also* in a webworker. We need to either consistently use it
or not use it - so let's use it.
