feat(send_queue): send redactions via the send queue

[Johennes]

This is a first step towards #4162 and adds a way to send redactions (including their local echoes) via the send queue.

I had to introduce new variants for SentRequestKey and LocalEchoContent because in some room versions the redacted event ID sits at the top-level of the event rather than in content.

At the timeline level redactions are handled via a new boolean flag in AggregationKind::Redaction. Local echoes of redactions merely set a flag on the timeline event whereas remote echoes of redactions lead to actual redactions as before.

The FFI bindings will be updated in a follow-up PR.

• I've documented the public API Changes in the appropriate CHANGELOG.md files.
• This PR was made with the help of AI.

[codecov]

Codecov Report

❌ Patch coverage is 69.77778% with 68 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.78%. Comparing base (39255c0) to head (44bc666).
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
crates/matrix-sdk/src/send_queue/mod.rs	56.33%	29 Missing and 2 partials ⚠️
...rates/matrix-sdk-ui/src/timeline/controller/mod.rs	58.82%	14 Missing ⚠️
...rates/matrix-sdk-ui/src/timeline/event_item/mod.rs	31.57%	13 Missing ⚠️
...rix-sdk-ui/src/timeline/controller/aggregations.rs	56.25%	7 Missing ⚠️
crates/matrix-sdk-base/src/store/send_queue.rs	33.33%	1 Missing and 1 partial ⚠️
...trix-sdk/src/latest_events/latest_event/builder.rs	98.70%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6250      +/-   ##
==========================================
- Coverage   89.80%   89.78%   -0.02%     
==========================================
  Files         376      376              
  Lines      102634   102849     +215     
  Branches   102634   102849     +215     
==========================================
+ Hits        92166    92348     +182     
- Misses       6882     6923      +41     
+ Partials     3586     3578       -8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[codspeed-hq]

Merging this PR will not alter performance

✅ 50 untouched benchmarks

---

_{Comparing Johennes:johannes/send-queue-redactions (44bc666) with main (39255c0)}

[Johennes]

Sorry for the ping @bnjbvr. 🙈 Since we briefly spoke about this in the dev room, I was curious if you had any high-level thoughts on this change? I'm basically just trying to verify that this is moving into the right direction architecturally before spending more time on it. Any thoughts on this would be highly appreciated.

[bnjbvr]

Thanks for the ping. Proposed a slightly different implementation at the timeline level, so that users don't have to check two booleans to know if something's been redacted. Looks like you're on the right track, though!

[Johennes]

Thanks for the initial feedback. I think this is now ready for review. I've included sending redactions in the send queue and handling their local echoes in the timeline in two separate commits. There will have to be a follow-up PR to change the entry paths in the FFI and UI layer to actually use the send queue when sending redactions. I thought it might be good to exclude this here.

[bnjbvr]

Thanks, makes sense to me to keep this PR as minimal as possible, considering it's already 600LOC; thanks for thinking about this! I've posted a comment which might be more a question/a thing to double-check, with respect to the shape of the saved event in the DB (might be different based on the room version). Let me know if I'm completely wrong here :)

[bnjbvr]

Thanks! Sorry, I spotted a few more things, including one non-trivial question that might turn into an interesting experiment…

[bnjbvr]

Do we need to also do the little encryption dance, if the room was encrypted? I think redaction events can be encrypted, so we likely need to…

[Johennes]

No, I think the redaction event itself is always unencrypted. The SDK doesn't actually send it like a normal event. It calls PUT /_matrix/client/v3/rooms/{roomId}/redact/{eventId}/{txnId} and then the server inserts the actual event.

[bnjbvr]

shouldn't this bool be based on a field of send_error somehow?

[Johennes]

Hm, I think not. This is actually copied from the LocalEchoContent::Event match-arm a few lines above. It seems that send_error is of type QueueWedgeError which appears to always be unrecoverable.

/// Represents a failed to send unrecoverable error of an event sent via the
/// send queue.

[bnjbvr]

I realize I forgot to ask the previous time, but could we store the unredacted_content in MsgLikeKind::Redacted, or would it make the code super hard to read, or expose an internal implementation detail to the consumers of these APIs? I think it would be nice in that it would make it impossible to represent impossible states, but maybe it complicates things a bit too much, WDYT?

[Johennes]

Hm, I'm probably entirely misunderstanding but does unredacted_content not necessarily need to hold just a normal TimelineItemContent with any MsgLikeKind because we want to be able to restore the original content upon unredaction?

[Johennes]

Or wait, you mean move unredacted_content from here into MsgLikeKind::Redacted? But then we'd have a TimelineItemContent inside of MsgLikeKind?

Sorry, I'm most likely just being dense. 🙈