notification client: use the membership state to match an invite

[bnjbvr]

The notification client was relying on the SS proxy including the event_id of a stripped room membership event, to correctly match an invite. This is not the case anymore with SSS (in the spec, stripped events don't include an event_id, although I don't see any good reason why), so we have to resort to a different mechanism:

• stash an invite event for the current user, if found.
• use it, if and only if, the room was inferred by the notification client to be in the invited state, based on the sync.

With this change, matrix-sdk-integration-testing tests::sliding_sync::notification_client::test_notification integration test from #3983 passes correctly.

[codecov]

Codecov Report

Attention: Patch coverage is 37.50000% with 20 lines in your changes missing coverage. Please review.

Project coverage is 84.23%. Comparing base (aa92e26) to head (59553d6).
Report is 5 commits behind head on main.

Files with missing lines	Patch %	Lines
crates/matrix-sdk-ui/src/notification_client.rs	37.50%	20 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4000      +/-   ##
==========================================
- Coverage   84.27%   84.23%   -0.05%     
==========================================
  Files         266      266              
  Lines       28315    28328      +13     
==========================================
- Hits        23863    23862       -1     
- Misses       4452     4466      +14     

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

[Hywan]

I'm not sure it's gonna work with the latest version of Ruma. Either you transform user_id into the type of state_key, or you extract the user ID from state_key with state_key.user_id().

[bnjbvr]

This is rebased on main, so should be fine.

[bnjbvr]

(It's not a call room member event, but a general room member event.)

[Hywan]

Alright.