fix(ffi): add methods to make QR login handlers exit cooperatively

[Johennes]

With my Filament hat on: This add new methods on the QR login handlers to make them exit cooperatively by first dropping the updates task and then returning. We've found this necessary when using the React Native FFI bindings in release builds to prevent crashes when the futures are cancelled.

• I've documented the public API changes in the appropriate changelog files (see Writing changelog entries).
• This PR was made with the help of AI.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.86%. Comparing base (7b2b439) to head (551a2b6).
⚠️ Report is 21 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6677      +/-   ##
==========================================
- Coverage   89.86%   89.86%   -0.01%     
==========================================
  Files         396      396              
  Lines      110260   110260              
  Branches   110260   110260              
==========================================
- Hits        99088    99085       -3     
- Misses       7395     7397       +2     
- Partials     3777     3778       +1     

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

[codspeed-hq]

Merging this PR will not alter performance

✅ 50 untouched benchmarks

---

_{Comparing Johennes:johannes/cooperation (551a2b6) with main (567463d)}

[Hywan]

Thanks for the contribution. I think it makes sense but I've added a couple comments.

Would it be possible to move that inside the matrix_sdk crate? First off, it would allow proper testing, and second, it can be useful for Rust users too. Keep in mind the FFI crate is only about bindings, no logic at all.

[Hywan]

If it is biased, why do you want to give priority to login instead of self.cancel.notified()? Cancelling seems more important here, don't you think?

Please add a comment on biased to justify and explain it.

[Johennes]

Good point. On second thought, I think we don't actually need biasing here. The update from the QR flows depend on user interaction. They should come in sparsely which means biasing shouldn't really make any difference. Have removed it in e9a461d.

[Hywan]

biased would make a difference if two updates come at the same time. So I think we need it! Cancellation must have a higher priority.

[Johennes]

Hm, right. Ok, have reverted back to biased and added comments to explain it in 551a2b6.

[Johennes]

Would it be possible to move that inside the matrix_sdk crate? First off, it would allow proper testing, and second, it can be useful for Rust users too. Keep in mind the FFI crate is only about bindings, no logic at all.

That would be great but I'm not entirely sure how. The problem only exists because of the progress tasks and those only exist in the FFI crate.

[Hywan]

The problem only exists because of the progress tasks and those only exist in the FFI crate.

Yes, but there is no interaction between the cancellation and the progress listener. I think it's a safe feature to move into matrix-sdk.

Or, alternatively (I don't want and I don't like this solution but I'm providing an alternative here), add tests in matrix-sdk-ffi for that. But please, consider moving this code (plus adding a test) in matrix-sdk first.