feat(linked chunk): add a way to reconstruct a linked chunk from its raw representation

[bnjbvr]

What it says on the tin. Extracted from #4308, with extra testing and better error handling.

In particular, we must be careful that the passed set of chunks form a linked list, and not a looser kind of a graph.

Two things I'm not very sure about:

• should we have a dedicated pass only to check the internal links are consistent? I think what I've done is equivalent and correct (i.e.: manually check the previous, remove from self.chunks while constructing, ensure self.chunks is empty after iterating), but an explicit pass might be more straightforward and clearer in its intent.
• is it fine that Ends::last is always set? It's not clear to me why it should be optional, since its users will either take it, or take first when it's not set.

Part of #3280.

[codecov]

Codecov Report

Attention: Patch coverage is 82.66667% with 13 lines in your changes missing coverage. Please review.

Project coverage is 85.05%. Comparing base (1098095) to head (6e48c07).
Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
...ates/matrix-sdk-common/src/linked_chunk/builder.rs	81.69%	13 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4318   +/-   ##
=======================================
  Coverage   85.05%   85.05%           
=======================================
  Files         275      276    +1     
  Lines       30301    30376   +75     
=======================================
+ Hits        25772    25836   +64     
- Misses       4529     4540   +11     

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

[Hywan]

Okay, I've left a lot of comments but (!) I like the strategy you've taken: I think it's a valid one!

I am hesitant to ask the modify the build() method to run 2 phases:

1. check data consistency,
2. build the actual LinkedChunk

I suppose you've merged the 2 phases in a single one for performance reason, but it makes it a bit more complex to understand. Not a big deal though. I wonder if it has any performance impact in reality, as we may not build huge LinkedChunk, vs. having super clear and easy-to-understand code.

[bnjbvr]

Alright, please take another look. I'm not super satisfied with the splitting of the building into two parts (you'll see that some checks are redundant, with some branches that can't be hit, because of this), but this is likely semi-temporary code anyways.

The one thing I'm tempted to do is to get rid of all the error types and keep a single one "MalformedList", because the detail of what the error is only matters for the testing purposes…

[Hywan]

I think we are good!

[Hywan]

Nitpicking: This could have been a nice candidate for a:

Suggested change

	let mut first_id = None;
	for (id, chunk) in self.chunks.iter() {
	if chunk.previous.is_none() {
	// This chunk is a good candidate to be the first chunk.
	first_id = Some(*id);
	break;
	}
	}
	let first_id = self.chunks.iter().find_map(|(id, chunk)| chunk.previous.is_none().then_some(*id));

[Hywan]

Suggested change

	// There's no first chunk, but we've checked that `self.chunks` isn't empty:
	// There's no first chunk, but we've checked that `self.chunks` isn't empty in `Self::build`:

[Hywan]

👍