Add toy implementation of association entry processing

[neekolas]

Summary

This is not meant to be a real PR, but more of a discussion piece to weigh out the pros and cons of having self-contained credentials. Things like signatures are mocked, and I'm sure there are edge cases I haven't considered here.

The purpose of this spike was to figure out how manageable it would be to have a version of XID where clients could verify credentials without talking to the server.

We ultimately have to choose between a more complicated data structure on the client, or a more complicated distributed-systems problem keeping identity state synchronized between nodes.

This change makes the revocation code more complex in exchange for relaxing the need for clients to have an up-to-date view of the network state to validate credentials.

Architecture

To get the current state of an XID you need two inputs:

• The recovery log: contains any revocations that have happened with the XID
• The association log: contains all associations

The recovery log is always evaluated first, and generates the initial state. Each entry in the association log is then evaluated sequentially. An entry is all-or-nothing, if any validation fails no part of it will be applied and the state remains unchanged.

The idea here is that each client can present a credential that contains an association log leading from XID creation up to the Installation being added. Each group is able to store the Revocation Log of an XID in its GroupContext, so that all members have a consistent view of which revocations should be considered at any point in the group's life.

When evaluating a credential in a given epoch, each client has a consistent view of the two logs irrespective of the state of the backend. When a new revocation happens, the first member of a group to discover the Revocation event from the backend will publish it into the group state as a MLS proposal.

Revocations

We are looking for the following properties around revocation:

• You can revoke any entity (Address, Installation) that has been associated with a XID
• Revoking an entity will prevent new associations from being created with an existing_entity_signature from the revoked entity
• Entities created with an existing_entity_signature of a revoked entity are protected from revocation if they were added before the revocation
• Revoked entities can be re-added with a new signature and the re-added entity will have all the same permissions that it did before revocation
• The association log may be incomplete. When a subset of the full log is evaluated, all entities present in the subset will have the same revocation status that they have in the full log.

The code in this PR should hit all of these properties.

Notes

• I put the CreateXid into the revocation log in this PR. It may make sense to actually exist in both or to be considered separately from either.
• I still haven't worked out how to structure changes to the recovery address. Those may require consistent ordering on the server, although that ordering doesn't need to stay in sync with MLS group state at least.
• There are still some open questions around XID creation. All the solutions to that we have on the table should be compatible with this architecture and just require some tweaks to the logic.
• Our nodes will still need to maintain their own version of the association state. If entries are missing, this could cause validation issues for later entries. One mitigation would be to include the entire history when adding new associations, allowing the node to fill in any gaps it might have. That way a request that succeeded on one node would always succeed on any other node.