fix(crypto): Serialize sender data msk in base64 instead of numbers

[BillCarsonFr]

Follow up of #4449

While adding snapshot test, I detected that sender's data KnownSenderData was serializing the cross-signing master key as an array of number. This PR changes that and now serialize the key as a base64 string, adding migration for the old format.

• Public API changes documented in changelogs (optional)

Signed-off-by:

[BillCarsonFr]

I am not familiar with this serde visitor pattern. Let me know if it is sane or if there is a prefferred method? I am not sure about the error mappings

[richvdh]

Filed #4459 about the test failure

[codecov]

Codecov Report

Attention: Patch coverage is 73.33333% with 4 lines in your changes missing coverage. Please review.

Project coverage is 85.09%. Comparing base (d649606) to head (5ff556f).
Report is 2 commits behind head on main.

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

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4450      +/-   ##
==========================================
- Coverage   85.12%   85.09%   -0.04%     
==========================================
  Files         283      283              
  Lines       31775    31790      +15     
==========================================
+ Hits        27048    27051       +3     
- Misses       4727     4739      +12     

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

[andybalaam]

This looks good to me, and the error mappings look about right.

@poljar should Edd25519PublicKey serialize as base64 by default?

[poljar]

This looks good to me, and the error mappings look about right.

@poljar should Edd25519PublicKey serialize as base64 by default?

No, only if we serialize into JSON.

[poljar]

This looks good to me, and the error mappings look about right.
@poljar should Edd25519PublicKey serialize as base64 by default?

No, only if we serialize into JSON.

To expand on this, I think this PR is fine, but we don't want to move the base64 serialization into vodozemac, where Ed25519PublicKey is defined.