test: fix one potential race in `test_room_notification_count`

We're subscribing to settings updates *after* sending a request to change a setting. In an unlucky scenario, the following sequence of events could happen:

- sending request to change the settings
- response is received
- we set up the receiver to settings updates, but it's too late

The fix would then be to subscribe to the changes *before* we even send the request to update settings.

testing/matrix-sdk-integration-testing/src/tests/sliding_sync/room.rs

@@ -519,6 +519,8 @@ async fn test_room_notification_count() -> Result<()> {
     // Now Alice is only interesting in mentions of their name.
     let settings = alice.notification_settings().await;
 
+    let mut settings_changes = settings.subscribe_to_changes();
+
     tracing::warn!("Updating room notification mode to mentions and keywords only...");
     settings
         .set_room_notification_mode(
@@ -529,7 +531,7 @@ async fn test_room_notification_count() -> Result<()> {
     tracing::warn!("Done!");
 
     // Wait for remote echo.
-    timeout(Duration::from_secs(3), settings.subscribe_to_changes().recv())
+    timeout(Duration::from_secs(3), settings_changes.recv())
         .await
         .expect("timeout when waiting for settings update")
         .expect("should've received echo after updating settings");