crypto: Expose new stream about room_key withheld messages

[richvdh]

Part of the fix to element-hq/element-web#27653.

[Please ignore the branch name; I appear to have fat-fingered]

[codecov]

Codecov Report

Attention: Patch coverage is 94.44444% with 1 line in your changes missing coverage. Please review.

Project coverage is 84.30%. Comparing base (fac7221) to head (6b38e99).
Report is 18 commits behind head on main.

Files	Patch %	Lines
...atrix-sdk-crypto/src/store/crypto_store_wrapper.rs	93.75%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3660      +/-   ##
==========================================
+ Coverage   84.25%   84.30%   +0.04%     
==========================================
  Files         259      259              
  Lines       26622    26625       +3     
==========================================
+ Hits        22431    22446      +15     
+ Misses       4191     4179      -12     

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

[Hywan]

I can only review the code, not the feature. A second pair of eyes from @poljar might be useful.

[Hywan]

To use now_or_never, you must be sure that the value will be immediately available in the Stream, otherwise the test will be flaky.

Is it a problem to use next().await here instead? The risk is that the test might be pending forever if something changes in the future, but it's still an indication that a regression has been detected. The pros, however, is that we are sure the test can never be flaky.

[richvdh]

Is it a problem to use next().await here instead?

I guess not. TBH I pretty much cargo-culted this from test_megolm_encryption above, which afaik has never shown any sign of being flaky. Flipping it around: is there any reason to believe that the value would not already be available in the Stream?

[poljar]

The stream is created before we receive the sync changes, the sync changes trigger an update, this means that the now_or_never() should never fail here, unless we introduce a bug.

There are no hidden tasks/threads or requests being sent out in receive_sync_changes() it's all a pretty dumb, for better or worse, state machine.

now_or_never() is the right thing to use, otherwise a regression will produce a hang instead of a loud test failure.

[poljar]

I think that this looks fine. I would probably add a doc example but not required since it's a simple stream and we have plenty examples for streams.

[poljar]

The stream is created before we receive the sync changes, the sync changes trigger an update, this means that the now_or_never() should never fail here, unless we introduce a bug.

There are no hidden tasks/threads or requests being sent out in receive_sync_changes() it's all a pretty dumb, for better or worse, state machine.

now_or_never() is the right thing to use, otherwise a regression will produce a hang instead of a loud test failure.

[poljar]

Oh and thanks for taking the time to refactor the filter we had for each stream.