Store WebUI search tabs between app restarts and across sessions

[Piccirello]

This PR makes two major improvements to WebAPI/WebUI searches:

• Searches and their results are now persisted across qBittorrent restarts. This mimics the same behavior available in the GUI.
• All searches are now available to and shared among all WebAPI sessions. This makes sense given that qBittorrent's WebAPI is single user.

[glassez]

• This makes sense given that qBittorrent's WebAPI is single user.

But multi user access has been requested several times.
Is it generally rejected, so it won't be implemented for some time?

[Piccirello]

• This makes sense given that qBittorrent's WebAPI is single user.

But multi user access has been requested several times. Is it generally rejected, so it won't be implemented for some time?

It's been requested but I don't think anyone plans to build it. I personally think qBittorrent should remain single user.

[glassez]

It's been requested but I don't think anyone plans to build it.

Well, why is that? Given that web sessions are initially implemented as isolated, this is not so difficult to do in a simplified form (which is sufficient for most users requesting this). In addition, it would allow access through a restricted account, which, for example, would not have access to settings.

But if you prefer to nip this opportunity in the bud and you get the approval of the other members, well, so be it.

[Piccirello]

This isn't the first time this has come up on one of my PRs. The approach we've always taken is that we shouldn't prevent adding new features just because we "might" add multi user support some day. This PR also doesn't prevent us from adding multi user support, it would just need to be refactored a bit.

Well, why is that?

If I had to guess, it's because none of the maintainers use qBittorrent in a multi user setup.

[glassez]

If I had to guess, it's because none of the maintainers use qBittorrent in a multi user setup.

If qBittorrent only had what maintainers use, then it wouldn't have quite a lot of its current features.

[glassez]

@Piccirello
As for the PR itself.
Since you want to provide sharing search related data between web sessions, it would be easier to just have a single instance of the SearchController that lives outside of any WebSession (like AuthController does). Creating a separate instance of the controller per session served only to restrict access to the data of another session, so it no longer makes sense for SearchController.

[Piccirello]

I can make that change. However, in the past whenever I've wanted to share data across session instances, the recommendation has been to instantiate the data structure in WebApplication and pass it via the controller's constructor. I think this approach has the benefit that it follows the same pattern as all other controllers (except AuthController, which is unique). Won't using a different approach for SearchController be confusing? There's also no guarantee that all future SearchController data will be shared across clients.

[glassez]

I can make that change. However, in the past whenever I've wanted to share data across session instances, the recommendation has been to instantiate the data structure in WebApplication and pass it via the controller's constructor. I think this approach has the benefit that it follows the same pattern as all other controllers (except AuthController, which is unique).

It's not about the pattern (in the sense of simply choosing one of several equivalent ways). The design was based on the fact that sessions are supposed to be isolated from each other so all the controllers was instantiated inside the sessions by default. AuthController is an exception because (it is obvious that) "authentication" lives outside of sessions.
If we abandon the idea of multi-user access, then we can change it so that the controllers have one instance by default, with the exception of those that still require data isolation, such as SyncController (since it is unlikely that the synchronized state is supposed to be shared between sessions even in single user architecture).

Won't using a different approach for SearchController be confusing?

As I said above, this is not a different approach. This is a unified approach in which the controller instance lives in the area corresponding to its nature.

[glassez]

There's also no guarantee that all future SearchController data will be shared across clients.

Okay, that might make sense. Let's try to review it, since you've already done it this way. Although the first thought was "why make so many changes if you could just make the SearchController instance live outside of sessions?".

[glassez]

I would prefer to review SearchJobManager implementation after my current comments are addressed.

[glassez]

Yet another portion of review from me.
I'll try to get back to it ASAP.

[Piccirello]

Latest round of comments were very helpful, and all feedback has been addressed.

[glassez]

Still unfinished review...