Api tags patch

[snack32]

Excuse me for my intrusion, but this PR adds the possibility to filtering torrents by tags through the api in qbit 4.3.9.

Rationale:
The possibility of filtering torrents by tags (like the categories) through the api at the "/torrents/info" endpoint it was only implemented after 4.4.0 qbit version.

This implies that users of the legacy version (4.3.9) don't have this option and may lead to failures or broken things on custom web-ui (current or future).
I.e.: VueTorrent/VueTorrent#577

This simple patch (it simply adds 3 lines to original code in a single file) add this functionality and does not change any relevant.

Performed tests:
The patch is an exact copy of the original PR: qbittorrent/qBittorrent#15152
I have personally compiled a 4.3.9 qbit version following your script and steps (with the only difference of the added patch ) and I can confirm that the program works exactly the same as before, but with the addition that now torrents can be filtered through the api by the tags.

And anecdotally I can say that, for example, with this patch the vuetorrent web-ui filters perfectly by tags on dropdown list.

Thank you very much for your time and sorry for the inconvenience!

[userdocs]

Thanks for the PR and I can confirm it is the unmodified patch from here: https://patch-diff.githubusercontent.com/raw/qbittorrent/qBittorrent/pull/15152.patch

The issue here is that this repo needs to builds unmodified binaries that are being using downstream. Occasionally I apply a patch from a patch version like 4.5.0 < 4.5.1 and rebuild that version for critical fixes that I don't need to wait for a new release to apply.

This is not considered a modification as it is to fix something not add something.

This patch is from the 4.4.0 branch and not the 4.3.0 branch. Therefore is not a critical fix and would be considered modifying the client. So, I appreciate the testing and PR to provide knowledge of this option to people ( which appears OK and not really harmful in anyway I can think of) It cannot be included for the reason above.

So what is best is that I will leave this PR open for anyone to see and if they really want it,

• Fork this repo
• Enable the Actions workflows
• upload the patch to the patch dir
• build and release their own patched version.

I think that's the best way?

[snack32]

I think it's perfectly understandable your reasons and rationale.

Thanks for taking time to answer this PR and once again, I apologise for any inconvenience caused.

[userdocs]

It's fine to leave it open for people to see and read the comments, I just tagged it wontfix.