Reconsider drake's storage backend

[wlandau]

Prework

• Read and abide by drake's code of conduct.
• Search for duplicates among the existing issues, both open and closed.
• Advanced users: verify that the bottleneck still persists in the current development version (i.e. remotes::install_github("ropensci/drake")) and mention the SHA-1 hash of the Git commit you install.

Description

For its entire existence, drake has relied on the storr package as a caching backend. storr has an amazing API and internal design, and I love its namespace functionality. However, given #907 and #930 (comment), drake's demands may have exceeded storr's performance. We may need to implement a custom caching system someday. I hope we do not need to do anything so drastic, but the time has come to at least consider the possibility.

[wlandau]

To be worth the effort, the new cache would need to

• Meet or exceed these memory benchmarks.
• Achieve fst-like speeds for both small and large data.
• Use storr's API so we can swap it out and maintain back compatibility.

[wlandau]

Closing for now. drake's memory consumption far exceeds that of storr (re #932) and we should see speedups from richfitz/storr#111.

[wlandau]

From the last paragraph in richfitz/storr#77 (comment), there is a better way to work around the current limitations than to rewrite storr.