WIP [1.x] Externalize storage

[tomleavy]

Background:

As part of our 1.x goals, we want to externalize all storage objects that interact with mls-rs so internal functionality is not directly dependent on a user-provided storage mechanism.

Key Package Storage

Currently building a client requires that you provide an implementation of the KeyPackageStorage trait that we define in mls-rs-core. A Client uses this to maintain storage on your behalf when certain operations take place:

When a key package is generated with Client::generate_key_package_message, the Client will store the associated private key in the KeyPackageStorage implementation

When a group is joined with Client::join_group, the Client will first retrieve the private key that corresponds with the key package that was used to add it to the group and also delete that private key when the resulting Group is saved.

• [ ] #207
• [ ] #209

PSK Storage

PSK storage is currently set when building a client and is consumed whenever a PSK is required:

• Joining a group with Client::join_group

• Processing a commit that requires knowledge of a PSK with Group::process_incoming_message

• Producing a commit introduces or requires knowledge of a PSK with Group::CommitBuilder

• Producing an external commit introduces or requires knowledge of a PSK with Client::ExternalCommitBuilder

• [ ] #215

Group State Storage

Group State Storage is currently set when building a client and has three functions:

• loading a group state with Client::load_group

• loading an epoch state if not already cached in memory when a message is received with Group::process_incoming_message for a prior epoch

• writing group + epoch state updates when Group::write_to_storage is called

• [ ] #212

[mulmarta]

PSK is also used in Client::external_commit_builder