Redact event content when processing m.room.redaction events

[marwing]

I initially reported this in Element X iOS here: element-hq/element-x-ios#1441

Room previews on Element X iOS show the content of the last message, even if that message was redacted before. In an unencrypted room, this also happens on a freshly installed and logged in client, suggesting the proxy is sending the data when it shouldn't.
I first noticed this after upgrading my sliding-sync proxy to v0.99.5 running with the official docker image.

[kegsay]

There's two cases to consider here:

• Real-time streaming: the client sees the to-be redacted event first and then sees the redaction come in when it ends up getting redacted.
• Historical: the client asks for the last N timeline events and this includes both the to-be redacted event and the redaction.

The proxy can only partially help in the historical use case. When it sees a redaction, it can edit the DB to redact the event content. Then, when the client asks for the timeline, we can ensure we always send the redacted content.

The proxy cannot help for the real-time use case, because it has already told the client about the unredacted event content. This needs client code to redact the event content and update the message previews. If the client did this, this would work for both use cases.

In other words, this is ultimately a client issue, but the server can try to assist by patching things up retrospectively. It will improve data security to not keep copies of redacted content in the DB. These cases aren't unique to sliding sync or EX: they are general cases when handling deleted content.