Performance improvements

[radex]

Performance improvements to IncrementalIndexedDB:

• skip regenerating unique indices on save ~(since they're regenerated on load anyway)~ - this cuts save time in half (120ms to 60ms in my app)
• fix typo that caused idIndex (which is regenerated ~on load~ lazily) to be saved. On my Nozbe Teams account this cut full metadata save from 3.2MB to 2.5MB
• only save metadata chunks for dirty collections. On the same example app, this cut most DB saves from 2.5MB to as little as 2KB (if a few very heavy collections are not dirtied)
• add a hook to "on IndexedDB started fetching" event, which can be used to speed up an app by taking advantage of concurrency (IDB is multi-threaded)

And for all of LokiJS:

• opportunistically convert $in: Array queries into $inSet: Set queries if indexed search is not available - this changes O(n*m) search into O(n * log m) search which improved speed of a few of queries in Nozbe Teams by 4-10x.
• change unique indicies and idIndex to be generated lazily
  • In Nozbe Teams, generating these indices takes 70-150ms at launch, depending on account, but they're almost never needed to launch the app! In fact, they're rarely needed at all, since most records/documents are fetched via queries and then kept around for a while (not fetched by ID).
  • It's mostly opening the app with ID in url and updating documents that causes index to be built. But even then, almost never all are needed at once, so only an extra 20-50ms penalty is paid (once) on some action.
  • There's no real downside to this - worst case scenario, the indices will be generated at launch anyway (just called from a different function); best case - 150ms saved :)
  • Since until now, both were generated on load, backwards compatibility is preserved - saved DB without these indices will still load correctly

[radex]

Hi @techfort, this is ready for review now :)

[techfort]

@radex cheers! publishing on npm now