Mastodon: Add end-to-end encryption API

Fix #1093

A set of APIs required for the double ratchet encryption algorithm, specifically the Olm implementation developed by Matrix -- but it should be roughly the same as libsignal. An additional layer on top of it is so-called message franking, which allows encrypted messages to be reported to content moderators without compromising keys or message contents ahead of time while also preventing fake reports.

• Olm
• Message franking

Development of E2EE capabilities into the web UI is not in scope of this PR.

REST API overview

To support Olm, the following APIs are required:

• Uploading keys for a device (current app)
• Querying available devices of people you want to establish a session with
• Claiming a pre-key (one-time-key) for each device you want to establish a session with
• Sending encrypted messages directly to specific devices of other people

Message franking

The sending client generates a new HMAC key and includes it in the to-be-encrypted message. It then generates a HMAC-SHA256 value from the to-be-encrypted message and sends it along with the encrypted message. The server, when forwarding the encrypted message to the recipient, composes a metadata summary for the message that includes the HMAC-SHA256 value, and then signs it using its own key. This metadata summary is forwarded along with the encrypted message itself to the recipient and discarded.

Upon reception of the encrypted message, the receiving client verifies the decrypted contents match the HMAC-SHA256 value from the metadata summary using the HMAC key provided in the decrypted contents. If they don't match, the message is discarded.

Should the receiving client desire to report the encrypted message and reveal its contents to the content moderators, the metadata summary is sent along with the report. The server can then verify its own signature on it and trust that the revealed contents are authentic.

Federation

:warning: Requires design of new JSON-LD vocabulary.