Integration tests assume single-`sync_once()` state transitions causing flakes against any homeserver that batches differently than Synapse

[jevolk]

test_mutual_sas_verification and test_mutual_qrcode_verification (in testing/matrix-sdk-integration-testing/src/tests/e2ee/mod.rs) assert that each step of the SAS/QR verification dance becomes observable after exactly one call to SyncTokenAwareClient::sync_once(). That helper uses a 1-second long-poll timeout (testing/matrix-sdk-integration-testing/src/helpers.rs:228). The assertion pattern looks like:

bob_sas.accept().await?;
assert_matches!(bob_sas.state(), SasState::Accepted { .. });
alice.sync_once().await?;
assert_matches!(alice_sas.state(), SasState::Accepted { .. });

There is no retry loop and no wait_until_some. A single sync round-trip is expected to deliver every state transition.

This bakes a Synapse-specific timing assumption into the test contract: that whenever a peer commits a verification event, the receiver's very next /sync (within a 1s long-poll) will return that event AND any to-device prerequisites (e.g. m.room_key) needed to decrypt it AND the SDK will have time to process them and emit the state transition before sync_once() returns.

Whether they land in the same /sync response on the receiver depends on commit ordering, watcher/notify semantics, and whether the receiver's long-poll happens to wake between the two writes. The Matrix spec does not require atomicity between these.

The contract that should be tested is: "after the peer sends action X and we drive the client (sync, process events, send replies, etc.) for some bounded time, the verification state machine reaches state Y."

The contract that should not be tested is: "exactly one sync round-trip suffices."