[stub/BrowserStorage] reimplement and test the BrowserStorage stub

[spalger]

While working on another pull request that requires testing against a fake browser storage object, I ran into some stuff that the existing StubBrowserStorage didn't provide, and since the existing module was so tiny this technically is a rewrite.

• return null when an item is not in the store (like the browser does)
• the length property and keys() method, necessary for iterating the store
• the ability to limit its size

This PR implements all of these things and adds test for the stub itself.

[cjcenizal]

This looks like great code! It's difficult for me to judge its utility, though. What are the uses cases for this?

In my experience, I've tested storage-dependent code by spying on localStorage or sessionStorage interface methods, returning fake values where necessary, and asserting that they methods been called with the correct values. This way the test execution is unaffected by the implementation details of those APIs. Would this work for your use cases?

[spalger]

I guess I have a couple reasons why I moved from stubbing individual functions to stubbing the whole thing:

• The specific class I was testing was using sessionStorage in its constructor, so I would have had to stub the same methods in every fucnton on top of test specific stubs
• The size limit thing. I initially implemented that by stubbing the sessionStorage object and it was much more difficult to understand that way
• By making it a part of the shared stub other tests have the opportunity to utilize it

[cjcenizal]

LGTM

[tylersmalley]

LGTM 👍