Add MLS public keys to clients

[pcapriotti]

This PR introduces changes to the client API needed to support validation of MLS key packages. See https://wearezeta.atlassian.net/wiki/spaces/CORE/pages/553418860/MLS+implementation+in+wire-server#Changes-to-the-client-API for details.

The client JSON object now has an additional field mls_public_keys, containing an object mapping signature schemes to public keys, e.g.

{
  ...
  "mls_public_keys": { "ed25519": "GY+t1EQu0Zsm0r/zrm6zz9UpjPcAPyT5i8L1iaY3ypM=" }
  ...
}

At the moment, ed25519 is the only supported signature scheme, corresponding to MLS ciphersuite 1.

When creating a new client with POST /clients, the field mls_public_keys can be set, and the corresponding public keys are bound to the device identity on the backend, and will be used to veriy uploaded key packages with a matching signature scheme.

When updating a client with PUT /clients/:client, the field mls_public_keys can also be set, with a similar effect. If a given signature scheme already has a public key set for that device, the request will fail.

Tracked by https://wearezeta.atlassian.net/browse/FS-472.

Checklist

• The PR Title explains the impact of the change.
• The PR description provides context as to why the change should occur and what the code contributes to that effect. This could also be a link to a JIRA ticket or a Github issue, if there is one.
• If a cassandra schema migration has been added, I ran make git-add-cassandra-schema to update the cassandra schema documentation.
• changelog.d contains the following bits of information (details):
  • A file with the changelog entry in one or more suitable sub-sections. The sub-sections are marked by directories inside changelog.d.

[mdimjasevic]

This looks good! A couple of minor comments are inlined.

[pcapriotti]

I'm not sure why you prefer the more general type signatures. It makes it tricker to use CPS functions like withMVar, and since we're polysemising these things anyway, I would imagine having the concrete types in there makes it easier to turn this into an interpretation function without having to use any higher-order stuff.

[mdimjasevic]

I'm not sure why you prefer the more general type signatures. It makes it tricker to use CPS functions like withMVar, and since we're polysemising these things anyway, I would imagine having the concrete types in there makes it easier to turn this into an interpretation function without having to use any higher-order stuff.

This was just a suggestion. Of course, if you have good reasons not to have more general type signatures, that is fine. I'm not requesting to change them.