[quota-api] Rethink about the storage model (#2)

Old APIs are disappearing and new APIs/usages are emerging, it looks we're getting to a situation where we might want to redefine the API with a set of simpler, low-level storage primitives.

I imagined we could start over with a minimum API which has something like `requestStorageDurability`, `queryUsage` and storage pressure events, but there seem to be also several discussion points that are discussed at length in https://github.com/slightlyoff/StorageDurability#2.

A few common popular requests are:
* A simple API to 'promote' an app's entire storage to persistent
  * [Storage Durability](https://github.com/slightlyoff/StorageDurability) and [Storage API proposal](https://wiki.whatwg.org/wiki/Storage#Rough_plan) both trying to address this
  * Ability to request/set per-origin persistent quota (i.e. requestPersistentQuota) does not seem really necessary
  * Whether we want to have partial storage durability (in terms of space or time) is still in question, but it could be too complex
* Ability for websites to indicate that some data are important but some are not (so that not entire origin data is always deleted during eviction for non-durable data)
  * Currently two options are being discussed: storage pressure events and named storage areas possibly with priorities

Filing this issue on Quota API too for tracking the discussion and showing interest on collaboration-- I'm willing to integrate these new changes or collaborating on a new API whichever smoother.

/cc @annevk @sicking @davidsgrogan @jakearchibald

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/quota-api/issues/2