include definition of ExtensionState extension

[kkohbrok]

This PR is joint work with @psyoptix, @mulmarta and @raphaelrobert.

[rohanmahy]

Hi, @kkohbrok @psyoptix @mulmarta I realize that this has been approved, however I think it conflates three things:

• making GroupContext items that are hidden from non-members. This should be encrypted somehow rather than hashed. Hashing just pushes the problem of getting the context somewhere else
• the ability to patch the GroupContext is a problem we are also trying to solve with the (App)Sync proposal. Again, we don't want a hash here.
• incorporating GroupState for which the master copy of this data is elsewhere, but we want to have agreement on it. This is a great use of a hash.

[kkohbrok]

I'm not sure I understand what you're suggesting here. A couple of points:

• ExtensionState allows (safe) extensions to safely anchor state in the group context. As such it's a "lower-level" mechanism than AppSync as it's meant to be used by extensions (such as AppSync) rather than an application running on top of MLS.
• ExtensionState doesn't preclude extensions from storing encrypted data. I agree that hashing isn't necessarily the best way to limit visibility, mostly because the hash might leak data to the DS. I'd be okay with removing that sentence. However, as you point out using ExtensionState to anchor data in hash form is still useful.
• ExtensionState doesn't prescribe how individual extensions should patch their data. That's by design, as we assume that the extension will handle that in some other way, for example, via extension-defined proposals. So there's no redundancy with what AppSync is trying to do.