This PR introduces the concept of a transfer "Batch", which is a grouping of transfers at the time they are enqueued.

A new endpoint allows a caller (and in subsequent changes, slskd's UI) to group a number of desired files when enqueuing them, and another endpoint allows a caller to get the status for the batch and all associated transfer records. This paves the way for features like a wishlist, and should also alleviate some pain points for third parties that use the slskd API.

A batch has, in addition to a collection of transfer records, a SearchId allowing it to be associated with a search. This is (or will be) useful in determining whether a particular search was fulfilled.

Batches have an Options property that, for right now, contains only one thing, Destination. Right now this does nothing, but in subsequent changes will allow a caller to choose the directory for the files in the batch explicitly.

I have marked the existing endpoint used to enqueue groups of files as [Obsolete] internally and will remove it in the future, requiring that all transfers are enqueued in batches, even if it's just one file.

Testing

POST /batches

• 400 on validation error
• 200 and batch if no files were enqueued (warning logged)
• 207 if a mix of success and failures
• 201 and batch if one or more files were enqueued (warning if failed > 0)
• 404 if user is offline
• Batch record created
• Uses provided ID if there was one
• Batch record contains provided search id
• Transfers created with batch ID

GET /batches/{id}

• Returns 400 given non-uuid
• Returns 404 given non existent id
• Returns 200 + batch w/transfers given existing id
• Returned batch has empty transfers array if no transfers
• Transfers returned with batch are up-to-date