do not backoff remote device key queries when a request fails due to backoff

The previous logic would increment the backoff counter both when a
request actually fails and when we do not make a request because the
server was already in backoff. This lead to a positive feedback loop
where every request made while a server is in backoff increases the
backoff delay, making it impossible to recover from backoff unless the
entire backoff delay elapses with zero requests.

book/changelog.md

@@ -209,6 +209,10 @@ This will be the first release of Grapevine since it was forked from Conduit
     after a successful request, causing an increasing rate of key query failures
     over time until a server restart.
     ([!149](https://gitlab.computer.surgery/matrix/grapevine/-/merge_requests/149))
+23. Fix bug where remote key queries that were skipped because the target server
+    was in backoff would increment the backoff delay further, leading to a
+    positive feedback loop.
+    ([!149](https://gitlab.computer.surgery/matrix/grapevine/-/merge_requests/149))
 
 ### Added
 

src/api/client_server/keys.rs

@@ -498,6 +498,8 @@ async fn request_keys_from(
     server: &ServerName,
     keys: Vec<(&UserId, &Vec<OwnedDeviceId>)>,
 ) -> Result<federation::keys::get_keys::v1::Response> {
+    check_key_requests_back_off(server).await?;
+
     let result = request_keys_from_inner(server, keys).await;
     match &result {
         Ok(_) => reset_key_request_back_off(server).await,
@@ -513,8 +515,6 @@ async fn request_keys_from_inner(
     server: &ServerName,
     keys: Vec<(&UserId, &Vec<OwnedDeviceId>)>,
 ) -> Result<federation::keys::get_keys::v1::Response> {
-    check_key_requests_back_off(server).await?;
-
     let mut device_keys_input_fed = BTreeMap::new();
     for (user_id, keys) in keys {
         device_keys_input_fed.insert(user_id.to_owned(), keys.clone());