feat(protocol): folder requests, and heuristics matched to other clients

Reading Nicotine+ and slskd against what was just written turned up three
places where this client had the message right and the behaviour wrong.

Excluded search phrases (code 160) are not a filter on the searches we
send — the server already drops those. Nicotine+ applies them to the files
it offers, leaving out any whose path carries an excluded phrase, and a
reply with nothing left is not sent. Ours now does the same, and the
local refusal of outgoing searches is gone.

Serving children now follows the same rules as Nicotine+: the limit comes
from the server's ParentMinSpeed and ParentSpeedRatio against the upload
speed the server records for us (capped at ten, none at all below the
minimum), children are refused until something feeds us the search stream
and let go when it stops, a second link from a child we already carry is
refused, and AcceptChildren is re-sent whenever that answer changes. Where
the server has never reported our speed there is nothing to apply the
formula to, so the configured cap stands, which is how slskd runs.

Queued downloads now ask where they sit every five minutes, as Nicotine+
does, instead of only when a caller asks; a brokered file connection we
cannot complete reports CantConnectToPeer like a control connection does;
and a peer's shares can be asked for one folder at a time (peer code 36
and its reply, 37), which is what "download folder" is built on.

soulseek-rs-lib/src/client/social.rs

@@ -166,6 +166,42 @@ impl Client {
         ))
     }
 
+    /// Ask `username` for the contents of one folder of their shares (peer
+    /// code 36) — what "download folder" in other clients asks for, without
+    /// pulling their whole listing.
+    ///
+    /// The answer arrives asynchronously; take it with
+    /// [`Client::take_folder_contents`].
+    ///
+    /// # Errors
+    /// [`crate::SoulseekRs::NotConnected`] when there is no server connection,
+    /// or [`crate::SoulseekRs::LockPoisoned`] if the client state is poisoned.
+    pub fn request_folder_contents(
+        &self,
+        username: &str,
+        folder: &str,
+    ) -> Result<()> {
+        let request = crate::message::peer::build_folder_contents_request(
+            crate::client::next_search_token(),
+            folder,
+        );
+        self.send_to_peer_or_queue(username, request)
+    }
+
+    /// Remove and return the listing of `folder` from `username`, once their
+    /// answer to [`Client::request_folder_contents`] has arrived.
+    #[must_use]
+    pub fn take_folder_contents(
+        &self,
+        username: &str,
+        folder: &str,
+    ) -> Option<Vec<crate::SharedDirectory>> {
+        self.context
+            .write_safe()
+            .ok()
+            .and_then(|mut ctx| ctx.take_folder_contents(username, folder))
+    }
+
     /// Ask `username` where the file we queued with them sits (peer code 51).
     ///
     /// The answer arrives asynchronously and lands on the download, readable