sliding sync: lazily generate and include the transaction id, only if it's useful

[bnjbvr]

The txn_id (transaction id) was always being generated, and this confused the sliding sync proxy server. As per the spec, it's useful to include it only when the request parameters have changed. As a matter of fact, we were slightly deviating from the spec by always generating one, and even then it would cost us bandwidth we could avoid.

With this patch, the transaction id is now lazily generated by any StickyManager that would make use of it, and included in the request only if it was generated and used by any set of sticky parameters.

[codecov]

Codecov Report

Patch coverage: 100.00% and project coverage change: -0.01 ⚠️

Comparison is base (8aa12c9) 75.61% compared to head (1a463f8) 75.60%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2063      +/-   ##
==========================================
- Coverage   75.61%   75.60%   -0.01%     
==========================================
  Files         149      149              
  Lines       16163    16170       +7     
==========================================
+ Hits        12221    12225       +4     
- Misses       3942     3945       +3     

Impacted Files	Coverage Δ
crates/matrix-sdk/src/sliding_sync/list/mod.rs	90.86% <100.00%> (ø)
crates/matrix-sdk/src/sliding_sync/mod.rs	91.70% <100.00%> (+0.04%)	⬆️
...s/matrix-sdk/src/sliding_sync/sticky_parameters.rs	100.00% <100.00%> (ø)

... and 1 file with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[Hywan]

It looks good to me. Nice to see how it fits well with the sticky parameters API \o/.

I'm not a big fan of having &mut Option<OwnedTransactionId>. It doesn't feel ultra safe as at any point in the workflow, it's possible to change this value, by any“one” (by mistake). Do you think we could improve this?

[bnjbvr]

I'm not a big fan of having &mut Option. It doesn't feel ultra safe as at any point in the workflow, it's possible to change this value, by any“one” (by mistake). Do you think we could improve this?

Yep, made a small wrapper that just hides the Option, so it guarantees it's only set once 👍