crypto: improve SenderData stored with room key bundle data

[richvdh]

If we already have cross-signing details for the owner of the device at the point we receive the to-device message, we should store that rather than just the device info.

To enable this, we have a couple of preparatory commits which factor out some code from SenderDataFinder so that we can reuse the same logic when we receive the key bundle data.

Suggest review commit-by-commit

Part of element-hq/element-meta#2685

[codecov]

Codecov Report

Attention: Patch coverage is 92.59259% with 2 lines in your changes missing coverage. Please review.

Project coverage is 85.90%. Comparing base (ff32840) to head (f349a66).
Report is 39 commits behind head on main.

Files with missing lines	Patch %	Lines
...x-sdk-crypto/src/olm/group_sessions/sender_data.rs	90.47%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4988      +/-   ##
==========================================
+ Coverage   85.89%   85.90%   +0.01%     
==========================================
  Files         325      325              
  Lines       35731    35733       +2     
==========================================
+ Hits        30690    30697       +7     
+ Misses       5041     5036       -5     

☔ 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.

[poljar]

Left a couple nits about the panics here.

[poljar]

Can't we instead treat that the same way as we treat the None case up above?

And let a test ensure that we always handle this properly?

[richvdh]

You mean, ignore the to-device message, rather than panic?

I suppose so, though generally I take the view that "unreachable" code should cause a crash so that you get an early warning that your previous assumptions no longer hold.

[poljar]

Well ok, I guess it's marginally easier to see where the assumption changed if we panic here instead in a test.

[richvdh]

As for a test: what did you have in mind? receive_room_key_bundle_data is private so can't easily be called directly from a test, as are its callers. And, for obvious reasons, we can't test this by injecting a to-device message with a mis-signed sender_device_keys.

[poljar]

I just assumed that testing the happy path here would be enough to ensure that the assumption didn't change.

[richvdh]

If you don't have strong opinions on this one, I'd like to leave it as-is. I think otherwise we end up with more unreachable (and untestable) code.