Implement getting verification cancellation info in Rust crypto

[uhoreg]

Fixes element-hq/element-web#26652

Checklist

• Tests written for new code (and old code if feasible)
• Linter and other CI checks pass
• Sign-off given on the changes (see CONTRIBUTING.md)

---

Here's what your changelog entry will look like:

🐛 Bug Fixes

• Implement getting verification cancellation info in Rust crypto (#3947). Fixes Element-R: User Verification: If one user cancels the request (or it times out), this is not reflected at the other user's end element-hq/element-web#26652.

[uhoreg]

Don't know if I need tests for this

[richvdh]

Don't know if I need tests for this

Yes please. (I'm a bit surprised the coverage metrics are happy, but whatever).

There are already some tests in https://github.com/matrix-org/matrix-js-sdk/blob/c24f38fa1783862f361b2ee80e6c6698d7c7091c/spec/integ/crypto/verification.spec.ts which do cancellation. It should be pretty easy to add some calls to these getters to check that they give the right value.

[uhoreg]

I realized that cancelInfo.cancelCode() returns a matrix-rust-sdk-crypto-wasm verification.CancelCode, rather than a ruma::events::key::verification::cancel::CancelCode, which on the JavaScript side just becomes a mostly meaningless number. I think that the best way to fix this is to make cancelInfo.cancelCode() return a string, which is the .to_string()-ed ruma CancelCode (since the string is all that the JS side cares about), though that of course would require incompatible changes to the wasm bindings. I could get away without changing the wasm bindings by putting a map of numbers to the string equivalents in rust-crypto/verification.ts, but that seems kludgy.

and if we can get rid of the cancel_with_code function from the Rust binding, or make it take a String instead (it looks like nothing in the JS SDK calls that function), then we can get rid of the wasm version of CancelCode completely.

[richvdh]

I realized that cancelInfo.cancelCode() returns a matrix-rust-sdk-crypto-wasm verification.CancelCode, rather than a ruma::events::key::verification::cancel::CancelCode, which on the JavaScript side just becomes a mostly meaningless number. I think that the best way to fix this is to make cancelInfo.cancelCode() return a string, which is the .to_string()-ed ruma CancelCode (since the string is all that the JS side cares about), though that of course would require incompatible changes to the wasm bindings. I could get away without changing the wasm bindings by putting a map of numbers to the string equivalents in rust-crypto/verification.ts, but that seems kludgy.

and if we can get rid of the cancel_with_code function from the Rust binding, or make it take a String instead (it looks like nothing in the JS SDK calls that function), then we can get rid of the wasm version of CancelCode completely.

Yes, all this sounds sensible to me. Don't worry about making breaking changes to the wasm bindings.

[uhoreg]

wasm PR is at matrix-org/matrix-rust-sdk-crypto-wasm#71

The tests on this PR won't pass until it gets merged, and this PR is updated to use the new code (which I assume means just waiting for a new release of the bindings and then bumping the required version number in package.json)

[uhoreg]

I merged in develop, which depends on the latest crypto wasm bindings. So the tests now pass.

[richvdh]

lgtm

[richvdh]

I feel like there are quite a lot of codepaths here which we're not testing at all, but I won't insist for now :)