feat!: wishlist, upload-queue privilege recognition, and search filters (#20)

Closes the last two gaps in Soulseek's list of features an alternative client must implement to be tolerated, and adds the result filters Nicotine+ has had all along. Wishlist: server code 103 is sent and code 104's announced interval is kept rather than logged and discarded, so the re-search timer runs off the schedule the server set. `wish add|remove|list|run` plus `serve --wishlist`; wishes persist in config.toml as a TOML array so a comma inside a query survives. `wish run` prints search-shaped records, so it pipes into `download --stdin`. Privilege recognition: the code-69 user list is parsed instead of counted and dropped, and code 92 answers `whoami` as `privilege_seconds`. Uploads now go through a queue with a slot cap (`--upload-slots`, default 2) that serves privileged users first — the cap is what makes the ordering mean anything, so they are one change. `PlaceInQueueRequest` (peer code 51) is answered, where it previously had no handler at all, and a departed peer's slot is released so a stalled peer cannot wedge uploads shut. Search filters: `--exclude`, `--extension`, `--min-size`, `--max-size` beside the existing `--min-bitrate` and `--free-slots`, in one flattened arg group shared by `search`, `get` and `wish run`. Also serialises the library e2e suite behind the same gate `cli_e2e` already uses: the new queue tests hold peer sockets open on purpose, which starved concurrently-spawned soulfinds and failed unrelated download tests with `login: Timeout`. BREAKING CHANGE: `UploadStatus` gains a `Queued(u32)` variant, so an exhaustive match on it no longer compiles, and `cli::Commands` gains `Wish`.
2026-07-26 14:20:07 +02:00
parent eda762d067
commit 9b87bd6a0f
29 changed files with 2991 additions and 145 deletions
@@ -0,0 +1,45 @@
+use crate::{
+    message::{Message, MessageHandler},
+    peer::PeerMessage,
+};
+use std::sync::mpsc::Sender;
+
+/// `PlaceInQueueRequest` (peer code 51): a peer asking where the file they
+/// queued sits in our upload queue.
+///
+/// Worth answering rather than dropping: a downloader that gets no position
+/// cannot tell a long queue from a client that has forgotten about it.
+pub struct PlaceInQueueRequest;
+
+impl MessageHandler<PeerMessage> for PlaceInQueueRequest {
+    fn get_code(&self) -> u8 {
+        51
+    }
+
+    fn handle(&self, message: &mut Message, sender: Sender<PeerMessage>) {
+        let filename = message.read_string();
+        let _ = sender.send(PeerMessage::IncomingPlaceInQueueRequest(filename));
+    }
+}
+
+#[cfg(test)]
+mod tests {
+    use super::*;
+
+    #[test]
+    fn the_asked_about_filename_is_forwarded() {
+        let (tx, rx) = std::sync::mpsc::channel();
+        let mut message = Message::new();
+        message.write_raw_bytes(vec![0u8; 8]);
+        message.write_string("@@share\\track.mp3");
+        message.set_pointer(8);
+
+        PlaceInQueueRequest.handle(&mut message, tx);
+        match rx.try_recv() {
+            Ok(PeerMessage::IncomingPlaceInQueueRequest(filename)) => {
+                assert_eq!(filename, "@@share\\track.mp3");
+            }
+            other => panic!("unexpected: {other:?}"),
+        }
+    }
+}