(Update) Don't query database in filter api take 2

[Roardom]

Take 2 of #4131

[what-the-diff]

PR Summary

• Improved Torrent Search Result Handling
  Enhancements to Torrent filtering logic, with updated caching and pagination for better search result management.
• Enriched Torrent Information
  Additional attributes like poster, genres, and metadata IDs incorporated for more comprehensive data on torrents.
• Simplified Pagination
  Switched to a less complex pagination structure by implementing simplePaginateRaw for search results.
• Expanded Search Capability
  Now, description, mediainfo, and bdinfo attributes included enhancing search indexing of torrents.
• Better API Response
  Implemented a more comprehensive structure in JSON response, now featuring pagination links and meta information, improving API clarity.

[HDVinnie]

I have reviewed this twice now. Still worried lol. Can you review it again yourself as well @Roardom

[Roardom]

The only sensitive info meilisearch stores is username for anon torrents, which is properly dealt with by return Anonymous for the uploader username if the anon flag is checked.

The only data being added to the return collection that isn't from meilisearch is the tmdb image url, the created_at date, and the route to torrents.show, which contains a numeric id parameter.

• The tmdb image url function does not output any sensitive data.
• The created_at date does not output any sensitive data
• The torrents.show route does not output any sensitive data - the id is not considered senstive

The above only concerns the cached data. After the cached data is fetched from cache, it alters the data before sending as response (but does not alter the data in the cache). It adds sensitive info to the response, such as the rsskey, which itself provides access to the passkey via the magnet link or by downloading the torrent. This sensitive data is not cached. The sensitive data is sourced from the auth helper, and not through an existing (possibly incorrect) user object.

We were originally concerned about apikeys leaking through the pagination urls, but that doesn't seem to be the case since other users' apikeys are never cached.