Define a permission store (closes #384)

[johannhof]

This is a draft attempt at defining a permission store with a couple of questions still to be figured out, some of which are also marked as issues inline. Some high-level thoughts:

• I've so far declared a single global permission store to be maintained by UAs, is that what we were shooting for?
• We should still allow for UAs to have more flexibility in storing smaller-scoped or shorter-lived permissions, e.g. for a single tab. It feels like this needs to be a non-normative note as attempting to specify that might go against the idea that it can be flexible.
• This ignores a lot of details around how we need to cross the process boundary to access permissions, though I've tried to make setting (and removing) permissions an async step.
• As discussed with Anne before, there's the question of whether individual permissions should define their own key generation algorithms or whether they should get if-statements in the central key generation algorithm.

Requesting an early look/advice from @annevk and @jyasskin :)

---

Preview | Diff

[annevk]

Thanks @johannhof for this draft. The general shape of this looks right, but there's a lot of details that need to be written out. I left a bunch of inline comments that I hope are helpful.

[johannhof]

@annevk I updated this PR (and privacycg/storage-access#138 which shows the usage) to allow for features overriding permission key algorithms without monkey-patching. Feel free to take another look and I'm happy to chat about it :)

[johannhof]

@annevk and I went through this draft again today and discussed some improvements, which I noted down in the review here. Anne also filed a couple of bugs where we found issues that weren't caused by this patch. I'll finish up the remaining points in this review and then I think we're ready to move out of WIP state and up to general review (and merge, hopefully).

[marcoscaceres]

Should also eventually deal with #348 (i.e., with the automation part)

[johannhof]

Ok I think this is ready for prime-time review and (hopefully) merge. The build is failing because for some reason [=origin=] isn't a valid reference anymore, happy to get pointers to that.

[johannhof]

And I just want to acknowledge that there is definitely some follow-up work given some of the issues e.g. around lifetimes vs. keys and automation (as Marcos mentioned), but I think this is a pretty good scope for a single PR right now and can stand pretty well on its own without introducing too much inconsistency until we get to those follow-ups.

[johannhof]

@marcoscaceres @miketaylr I'd love to get your review whenever you have a few minutes. I know a lot happened here but the overall diff shouldn't be that much to review. :)

[miketaylr]

LGTM - thank you!

[marcoscaceres]

Thanks @johannhof! I'm going to review it today.

[marcoscaceres]

lgtm... just a nit.

[marcoscaceres]

@johannhof, feel free to merge is you are done making any changes.

[johannhof]

Thank you, @marcoscaceres! I think we're good to merge!

[johannhof]

Looks like the tidy job for this failed on main, will there be an automated PR for that or should I push a manual fix to main?

[miketaylr]

A bot usually handles that (#406). All good!