Leverage "sealed sender" to encrypt message sender

After inquiring on #matrix, @uhoreg suggested I create an issue here so that there's a record of this topic.

I'm interested in the potential to reduce the amount of metadata a server is exposed to for messages in encrypted rooms. The folks over at signal had a clever (as usual) idea they're calling [sealed sender](https://signal.org/blog/sealed-sender/). It seems like this could be pretty easily applied to matrix.

The idea has two parts
1. a sender cert issued by the sending user's home server
2. ~~a recipient token known only to participants of the room (this is a symmetric secret shared with the room host server)~~

The flow might go basically like
1. sender signs each message with the sender cert and encrypts it for the recipient
2. sender sends the message with the recipient token and no sender metadata (my matrix knowledge is weak here, would the sender send to their home server, or the room home server?)
3. recipient's server verifies the recipient token
4. recipient requests the sender cert from the sender home server and validates the message

IMO decreasing the amount of metadata being passed around to different servers would be a huge step forward in getting support for federation.

EDIT:
I've thought more about this and some initial issues became very obvious.
For starters a per-room secret is not going to work. That would be literally _giving_ the server a way to see who is in a room. Two solutions came to mind, the former is what I think is better, but I'm including the other for comparison.

Recipient key approach: similar to signal's delivery token, but with asymmetric tokens.
Each user generates an a key pair.
The user shares the verification key with their home server.
The user shares the signing key with each group they're a member of. New users to those groups can be given all the members keys by the member who invites them.
Abusive users can be blocked by rotating the key pair and not sharing the new key with the abusing user. This prevents the abusing user from using sealed sender so the host server can rate limit or block them.

Group-recipient key approach: similar to above, but instead of one recipient key per user there's one key per user per group. Each user would rotate their key for a group when a user leaves the group.
The upside of this approach is that no user can contact another using sealed sender outside of an existing group, so a sender could be blocked from using sealed sender one-on-one, but still allowed in a larger group.
The downside is that even though a server can't identify the members of a group from just the recipient id and key, a less-than-privacy-respecting server might be able to de-anonymize users using fingerprinting, etc and would then be able to identify group members based on sender fingerprint and recipient key (eg. A is talking to B#group1 and C is talking to B#group1, therefore A and C, are talking to each other with B in #group1).

No source files, tests, or entry points are named. Start by reading the issue and its linked Signal sealed-sender article, then compare the sender-cert, recipient-key, and group-recipient-key approaches. Done would require an agreed Matrix protocol design, including routing, verification, blocking, and privacy trade-offs.

Written by the indexing model from the issue text.