(possibly also rename revocations.txt in the profile to reflect additional uses)

Test coverage: We're missing test coverage for removal of entries (this isn't covered for the existing implementation). We could do with a test or two for setting and reading whitelist / enrolment state (though it's largely hitting the same code as the OneCRL bits). Tweaks: I need to make a minor change to blocklist-clients to read additions / removals rather than enumerating the whole of the collection data. The "migrate from revocations.txt" stuff needs a) moving the a different method, b) the file removal bit and c) to not have the unwrap() calls, since we don't want panics. Rationale: I've largely mirrored the XPCom interface in the SecurityState struct to allow us the use of ? to keep the actual implementation code clean, while still handling all error cases. I spoke with Nika about this - she's happy with the approach (XPCom in Rust is fine, provided there's no non-scriptable stuff). In future, it might be nice to use a different ffi approach for the non-JS callers but that doesn't feel important right now. Nika suggested we might want to get froydnj's eyes on this.

Ah, also, I've just spotted I actually need to implement IsBlocklistFresh - pref branch reading works fine but it's in a WIP patch. I'll move it over.

Pushed by dkeeler@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/1bd54f8dfd9e Cleanup storage in CertBlocklist to allow easy addition of new types of pair (e.g. whitelist entries) r=keeler https://hg.mozilla.org/integration/autoland/rev/b0d08863f7a5 cert_storage: create rkv environment and store only once to avoid races r=mgoodwin,jcj

Pushed by dkeeler@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/99079ab7e52e Cleanup storage in CertBlocklist to allow easy addition of new types of pair (e.g. whitelist entries) r=keeler https://hg.mozilla.org/integration/autoland/rev/5514aae0e34e cert_storage: create rkv environment and store only once to avoid races r=mgoodwin,jcj