Move Code Review browser data storage to better solution
Context
In essence, we are at the whim of other parts of the product or third party vendors (who - in this case, don't clean up their data).
This is a problem because:
- the data store we use (
localstorage) is single-tenant (no namespacing) - the data store we use (
localstorage) is very data-restrictive (5MiB by default)
As an additional - but important - note: data stored in localstorage is not well-indexed. It is a string-based key-value store, which means we can't easily query it and data is usually larger at rest because it has to be serialized.
Proposal
Migrate groupcode review to IndexedDB.
This extracts Code Review from the storage competition: by using our own databases (we are not limited to one!), we will not have to worry about forces outside of our control exhausting our storage capacity. This solves the two problems listed above:
- The IDB system is multi-tenant (roughly, though you could still intentionally access someone else's data from the same origin), since we access databases that are just for us.
- We should not use generic "GitLab-wide" databases.
- IDB also has very high data limits, if it has any at all.
- For example, in Firefox a single origin (e.g. all of GitLab) could store up to 50% of the disk (if we switch to persistent storage mode), or 10GiB (which is the default "best-effort" cap). This is essentially inexhaustible (although we should be cautious with a cavalier attitude toward data usage).
Side Effect
As a side effect of switching to IDB, we also get high-performance data querying (as part of the indexed nature of the data). This will enable future product enhancements like robust offline modes (and graceful handling of network unreliability), multi-user modes, etc.