refactor(crypto): Make the room key importing logic more generic

[poljar]

Part of #4513 and necessary for #4989.

Making this generic right now is a bit of a no-op, but eventually we'll also import the HistoricRoomKey type which requires this to be generic.

[codecov]

Codecov Report

Attention: Patch coverage is 47.05882% with 9 lines in your changes missing coverage. Please review.

Project coverage is 85.85%. Comparing base (08800f7) to head (7864b63).
Report is 69 commits behind head on main.

Files with missing lines	Patch %	Lines
...es/matrix-sdk-crypto/src/olm/group_sessions/mod.rs	0.00%	6 Missing ⚠️
crates/matrix-sdk-crypto/src/store/mod.rs	72.72%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5041      +/-   ##
==========================================
- Coverage   85.85%   85.85%   -0.01%     
==========================================
  Files         325      325              
  Lines       35855    35864       +9     
==========================================
+ Hits        30784    30790       +6     
- Misses       5071     5074       +3     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[andybalaam]

Looks good, one question.

[andybalaam]

Can this be IntoIter<T> or something, to avoid the collect() above when we call it?

[poljar]

Kinda, though it can't be just that, because we have a room_keys.len() call.

Which then makes all of the trait bounds even more complex.

The other option is to remove the len() call, but then our progress listener doesn't work anymore.

Don't think it's worth it to avoid this collect() call, after all, allocating a vector of references isn't that big of a deal.

[andybalaam]

Yep, agree it's fine as-is.

[andybalaam]

(Or pass in the length?)

[poljar]

(Or pass in the length?)

That sounds like it would be a bit of a clunky API, not terrible but clunky enough for me to rather take the allocation.

The only reason why we take a Vec<&Foo> vs a Vec<Foo> is so we can gather info about the specific key in the error branch if creating a InboundGroupSession fails.

Perhaps gathering the info before the try_into() call consumes the key would be the wiser choice if we really want to avoid the allocation.

[andybalaam]

I don't mind either way.

[poljar]

Alright, let's keep the allocation, if we change our mind I think gathering the info before the consumption of the key would be the way to go.