event graph: add an initial implementation

[bnjbvr]

This is mostly a demonstration of how to plug the EventGraph with the timeline, add some initial types and documentation, and how little it changes the timeline as a result.

One thing I'm not satisfied with is that the TimelineBuilder::build() function should really be fallible eventually, because the subscribe() would read events from the storage, which is fallible. I've tried to make it so, but in the sliding sync code we're lazily initializing a Timeline using TimelineBuilder, and that can't fail, or we'd need the caller to check the result each time. Needs to be properly solved now, or as the immediate next PR.

I've also started a WIP to move the support for read receipts (not unread counters yet) from the Timeline into the Event graph, as a further proof of concept, and I might wait for it before requesting review here.

I'll move back to draft as soon as I get some test results :-)

Part of #3058.

[andybalaam]

I like the direction, and so far as I understand it, this looks good. Thanks!

[bnjbvr]

(Trying a rebase with #3070, to see if I can reproduce the slow test run 🤔)

[bnjbvr]

Above push was another rebase, now that the integration test failure has been fixed in main.

[codecov]

Codecov Report

Attention: 16 lines in your changes are missing coverage. Please review.

Comparison is base (f5f8f47) 83.72% compared to head (0b7be11) 83.77%.

Files	Patch %	Lines
crates/matrix-sdk-ui/src/event_graph.rs	82.95%	15 Missing ⚠️
crates/matrix-sdk-ui/src/room_list_service/room.rs	83.33%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3061      +/-   ##
==========================================
+ Coverage   83.72%   83.77%   +0.05%     
==========================================
  Files         223      224       +1     
  Lines       23367    23454      +87     
==========================================
+ Hits        19564    19649      +85     
- Misses       3803     3805       +2     

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

[bnjbvr]

@andybalaam I consider there are enough changes that this justifies a new review, if you have some time. The new commits introduce the following changes:

• make the TimelineBuilder::build() function fallible (to avoid using expect() in that function), which meant sparkling Result in a few places, and making a few FFI functions fallible too.

And two bonus commits, that could be moved to another PR if judged controversial

• get rid of Room::poll_history as it's untested, unused in both EX apps, and likely too slow (it creates an independent timeline which will re-run its own backpagination and so on)
• get rid of SlidingSyncRoomExt::timeline(), as it was only used in a test function, and that avoids a few hoops in the one caller (and permits extra refactorings)

[andybalaam]

Still looks good. Note that something like poll_history is definitely going to be needed sometime, but happy for it to be removed if the implementation is no good. Any plan for how to do it better?

[bnjbvr]

Any plan for how to do it better?

Yeah, if the timeline becomes a pure view over an existing set of events, it could be resurrected as such and be much more performant.