Add "remove File" to UI & API

[ManiMatter]

By design, qBit does not remove data when setting files to "Do not download".
If users do not want these files, they need to remove them manually from the operating system.

The idea of this PR is to add an additional menu entry, whereby files can explicitly be removed.
This helps in two regards:

1. It is less painful than user having to go to the operating system and removing the files from there (as requested here, for example)
2. Downstream applications like sonarr may actually think the partial files are full downloads, since eventually the entire torrent will change to "Complete" and sonarr will then try to process the files. By allowing users to remove the files easily, sonarr would not stumple over the remains..

The proposal I'd have is that we add a menu entry, maybe like in the picture below.
This would hit a new API end point /fileRemove.

I have started having a go, and would appreciate

1. Your thoughts as to whether this even makes sense and fits the strategy of qbit
2. Help in coding it - my skills are quite basic. I have seen that certain methods like "remove File" are already available, but I struggle piecing it together.. Maybe with a few pointers on the starts in this PR, I can bring it further

[Chocobo1]

By design, qBit does not remove data when setting files to "Do not download".
If users do not want these files, they need to remove them manually from the operating system.

https://github.com/qbittorrent/qBittorrent/wiki/Frequently-Asked-Questions#i-configured-qbittorrent-to-not-download-some-files-in-a-torrent-but-they-still-appear-on-my-hard-disk-why-is-that
You'll induce a recheck later if you still insist and go and delete a file. It is a bad idea.

[ManiMatter]

By design, qBit does not remove data when setting files to "Do not download".
If users do not want these files, they need to remove them manually from the operating system.

https://github.com/qbittorrent/qBittorrent/wiki/Frequently-Asked-Questions#i-configured-qbittorrent-to-not-download-some-files-in-a-torrent-but-they-still-appear-on-my-hard-disk-why-is-that You'll induce a recheck later if you still insist and go and delete a file. It is a bad idea.

Thanks for the explanation, @Chocobo1.

Maybe I was overthinking this and a solution to my problem already exists:
There is an option called Keep unselected files in ".unwanted" folder
Some questions on that folder

1. When the download completes, do we remove the files that have been moved to .unwanted automatically?
   Answer: No
2. If somebody sets the priority for a given file to 0 (= do not download = unwanted), my take is that this setting moves it to the .unwanted folder. If the user then choses again to download it while the download is still ongoing, will that move the file back out of the .unwanted folder?
   Answer: Yes
3. If on a completed download user choses to also chose items to download that were previously marked as do not download, does the torrent resume downloading?
   Answer: Yes, but if there is a "temp" location set up in the settings where ongoing downloads are normally going to, this is ignored. The additional file is directly downloading into the "completed folder"

My take from above:
For 1) - could we add an additional setting that says "Remove .unwanted after completing torrent"? I think that would get us around the problem you pointed out @Chocobo1 which relates to the fact that torrents may download adjacent bits which may partially belong to files that were chosen as do-not download, since at the point the torrent is completed, there's nothing left to download and the problem would not be there anymore. Wdyt?

For 2) - nothing, works perfect as it is

For 3) - I think it would make sense that ongoing downloads also go to the /temp location in cases where the rest of the download has already been completed. What I wonder is how big of a change that would be. If we have a temp path variable on torrent level already now in our backend, then I think it shouldn't be big. But if we only have a path variable which gets updated once the download hits complete, then I think that this could be huge, since we'd be introducing a second path variable (temp path vs final path)... Wdyt?

Points 3) and 1) may be related. If we delete .unwanted files when moving to the completed-folder, then an additional (previously unwanted) file is downloaded, but then again marked as as "do not download", this file will completed/.unwanted folder, since the move has already taken place (and the additional download, as per point 3) goes directly to the completed folder). Therefore for 1), rather than doing the deletion of the .unwanted folder together with the moving from temp->completed, I think the setting "delete .unwanted" folder should be called every time when the download gets to 100% (completed)... If done this way, 3) and 1) are completely independent, and it would also work in setups where users do not use temp-locations. Wydt?

[HanabishiRecca]

No, you should not delete unwanted files, not automatically nor manually. Because it breaks integrity of adjacent pieces.

Which means:

1. You won't be able to seed such pieces. You will see errors in the log on client's attempt to seed them.
2. Recheck also will fail and force the client to redownload the broken pieces.

Good news are, you do save the space. After the files deletion and recheck, the broken pieces will be redownloaded into the .parts file, as if you unchecked them before even starting the download.

Ideally, we need to be able to move adjacent pieces into the .parts file automatically, instead of redownloading them. But unfortunately libtorrent has no means to do that afaik.

[github-actions]

This PR is stale because it has been 60 days with no activity. This PR will be automatically closed within 7 days if there is no further activity.