Make our background storage more size resilient

[danfinlay]

Related to #3071

Meta-issue to address #3071.

We now know that storage is overflowing for some users, and this may be causing vault loss.

We need to develop strategies to improve our storage size resilience, and implement them.

• Study what happens when background localstorage cannot write anymore. Is the storage instantly lost? Is there an opportunity to backup/recover?
• Study which portions of our persisted state take the most size (probably transactions).
• Review extension storage limits.
• Research other alternative storage strategies.
• Move our localStorage use to the better solution (storage.local).

[danfinlay]

Study what happens when background localstorage cannot write anymore. Is the storage instantly lost? Is there an opportunity to backup/recover?

While the write attempt fails, the storage seems to persist, suggesting this issue may not be causing any data loss.

[danfinlay]

Study which portions of our persisted state take the most size

• RecentBlocks (doesn't need to be persisted, should be removed from storage)
• BlacklistController is getting pretty big, could use own key.
• TransactionController

[danfinlay]

Review extension storage limits.

Looks like the clear correct path is storage.local.

From the MDN documentation:

Although this API is similar to Window.localStorage it is recommended that you don't use Window.localStorage in the extension code to store extension-related data. Firefox will clear data stored by extensions using the localStorage API in various scenarios where users clear their browsing history and data for privacy reasons, while data saved using the storage.local API will be correctly persisted in these scenarios.

The storage.local API could allow for unlimited storage.

[danfinlay]

storage.local API originally defined by chromium team in these docs.

[danfinlay]

Previous example of setting up MetaMask to use an async storage api here.

[danfinlay]

Turns out much of the work to use the extension.storage API properly was already done by @heyellieday in this PR, I've forked her work to leverage this for an easier fix. (Forget that other bounty, she gets a bounty for this).

[danfinlay]

Began the work converting to extension.storage in this branch.

It boots up fine, but doesn't seem to switch over to relying on this strategy yet (I tested by trashing the localStorage randomly and restarting after some persistance, and it reverted to first-time state, which it shouldn't do if it's falling back to a new strategy).

[kumavis]

https://sentry.io/metamask/metamask/issues/439253980/

[danfinlay]

@kumavis that particular sentry error refers to our send-form's persistence, not background, so it probably deserves its own issue.

[danfinlay]

Added to that branch:

• No longer writes to localStorage.
• Fixed issue where quantity of write attempts overwhelmed our pump to storage.local stream.

[danfinlay]

Fixes #3071