fix(timeline): maintain aggregations when an event is deduplicated

[bnjbvr]

Some context

An aggregation is an event that relates to another event: for instance, a
reaction, a poll response, and so on and so forth.

Some requirements

Because of the sync mechanisms and federation, it can happen that a related
event is received before receiving the event it relates to. Those events
must be accounted for, stashed somewhere, and reapplied later, if/when the
related-to event shows up.

In addition to that, a room's event cache can also decide to move events
around, in its own internal representation (likely because it ran into some
duplicate events, or it managed to decrypt a previously UTD event).
When that happens, a timeline opened on the given room
will see a removal then re-insertion of the given event. If that event was
the target of aggregations, then those aggregations must be re-applied when
the given event is reinserted.

Some solution

To satisfy both requirements, the [Aggregations] "manager" object provided
by this PR will take care of memoizing aggregations, for the entire
lifetime of the timeline (or until it's clear'd by some
caller). Aggregations are saved in memory, and have the same lifetime as
that of a timeline. This makes it possible to apply pending aggregations
to cater for the first use case, and to never lose any aggregations in the
second use case.

Some points for the reviewer

• I think the most controversial point is that all aggregations are memoized for the entire lifetime of the timeline. Would that become an issue, we can get back to some incremental scheme, in the future: instead of memoizing aggregations for the entire lifetime of the timeline, we'd attach them to a single timeline item. When that item is removed, we'd put the aggregations back into a "pending" stash of aggregations. If the item is reinserted later, we could peek at the pending stash of aggregations, remove any that's in there, and reapply them to the reinserted event. This is what the first version of this patch did, in a much more adhoc way, for reactions only; based on the current PR, we could do the same in a simpler manner
• while the PR has small commits, they don't quite make sense to review individually, I'm afraid, as I was trying to find a way to make a general system that would work not only for reactions, poll responses and ends. As a matter of fact, the first commits may have introduced code that is changed in subsequent commits, making the review a bit hazardous. Happy to have a live reviewing party over Element Call, if that helps, considering the size of the patch.
• future work may include using the aggregations manager for edits too, leading to more code removal.

[codecov]

Codecov Report

Attention: Patch coverage is 81.03448% with 55 lines in your changes missing coverage. Please review.

Project coverage is 85.71%. Comparing base (ce44c6e) to head (da828c3).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
...rates/matrix-sdk-ui/src/timeline/controller/mod.rs	71.87%	18 Missing ⚠️
...rix-sdk-ui/src/timeline/controller/aggregations.rs	88.49%	13 Missing ⚠️
crates/matrix-sdk-ui/src/timeline/event_handler.rs	84.84%	10 Missing ⚠️
...trix-sdk-ui/src/timeline/event_item/content/mod.rs	61.53%	10 Missing ⚠️
...ix-sdk-ui/src/timeline/event_item/content/polls.rs	55.55%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4576      +/-   ##
==========================================
- Coverage   85.73%   85.71%   -0.03%     
==========================================
  Files         292      292              
  Lines       33492    33549      +57     
==========================================
+ Hits        28715    28756      +41     
- Misses       4777     4793      +16     

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

[andybalaam]

A live review party sounds good to me, and I've asked some other members of the Rust team whether they'd like to join because I'm not sure I should look at this on my own.