torznab profiles framework

[rraymondgh]

Upfront admission - this addresses 2 issues and 1 PR. (Failed on objective a PR should only address one issue). #185 and #311 It will also replace PR 308. I will also close PR 369. Incorrect leachers will be a self contained PR. Links to permalinks from arrs I expect to do after this PR has been merged. (Will benefit from configuration and settings capability in this framework PR). Similarly #349 will benefit from this framework capability and hence on hold until this PR is merged.

This PR enables torznab profiles to be defined using standard bitmagnet configuration framework. Using config.yml profiles can be defined:

torznab:
# [relevance, published_at, updated_at, size, files_count, seeders, leechers, name, info_hash]
  profiles:
    proxysearch: 
      tags: sonarr,radarr
    published: 
      order_by: published_at
      order_direction: descending

The existing torznab end point has been retained. For example: http://bitmagnet:3333/torznab/api. It uses a default profile:

"Profiles": {
    "default": {
      "OrderBy": "relevance",
      "OrderDirection": "Descending",
      "Tags": []
    }
}

An additional end point has been added. /torznabv2/:profile/*any. A new top level path is required due to to gin limitations that does not allow torznab/*any and /torznab/:profile/*any to co-exist. It has been considered important to maintain backwards compatibility so all users are not mandated to update their URLs on release.

The profiles are lazy validated on startup. (Hence separation of Config and Settings structs) If a profile is defined that requests sorting by an unsupported column or using a sort order that is invalid, it will fail on startup with an appropriate log. For transparency the setup profiles (including default profile) are logged on successful validation. Within this process default profile is created if not defined in configuration.

The actual changes to existing code are quite limited. Have done a minor re-factor of httpserver.go to better support multiple routes.

[mgdigital]

Can the profile be strongly typed instead of just map[string]string? Also can hostname be part of the profile?

[rraymondgh]

Relates to next point. Config framework does not work well with strongly typed structure. Also need a reasonable way to feed back to user that configuration is invalid.

[mgdigital]

It works well throughout the rest of the application, let me know if you have a specific issue with it

[mgdigital]

I think we should only add Profile model.NullString to this struct, and handle the rest in the adapter package instead of in httpserver.

[rraymondgh]

just passed through theProfile that has been selected by gin route. have used profile for controlling logging in httpserver

With logging have assessed:

sonarr - interactive and quick search
INFO	httpserver/httpserver.go:83	[192.168.1.202] t=tvsearch&extended=1&cat=5030,5040,5045,5000&imdbid=<<redact>>&season=1&ep=7&limit=100&offset=0
INFO	httpserver/httpserver.go:83	[192.168.1.202] t=tvsearch&extended=1&cat=5030,5040,5045,5000&season=1&ep=7&q=<<redact>>&limit=100&offset=0

sonarr polling
INFO	httpserver/httpserver.go:83	[192.168.1.202] t=search&extended=1&cat=5030,5040,5045,5000&limit=100&offset=0

radarr - interactive and quick search
INFO	httpserver/httpserver.go:83	[192.168.1.202] t=movie&extended=1&cat=2030,2040,2045,2060,2000&tmdbid=<<redact>>&imdbid=<<redact>>&limit=100&offset=0

all by will by order by published_at with exception of:

INFO	httpserver/httpserver.go:83	[192.168.1.202] t=tvsearch&extended=1&cat=5030,5040,5045,5000&season=1&ep=7&q=<<redact>>&limit=100&offset=0

This can be overridden by DisableOrderByRelevance

I have not managed to generate a scenario that reproduces problem noted in issue #185 Addition of logging will help if it continues to be an problem.