Allows users to specify custom logic contition checks for torrents

[Drapersniper]

Note: This is unlikely to be added due to the extra complexity it would add that being said making an issue now for tracking purposes.

A quick brainstorm to the idea mean the following:

1 - User would create a custom condition config file (json - Simplicy or yaml - Simplicy + redability or toml - restrictive and consistency)

rules:
  stale:
    - "{0}.progress < 1.0 AND {0}.availability < 1.0"
    - "{0}.state_enum in [METADATA_DOWNLOAD, STALLED_DOWNLOAD]" 
  slow:
    - |
        "
            {0}.state_enum != TorrentStates.PAUSED_DOWNLOAD
            AND {0}.state_enum.is_downloading
            AND 0 < 36000 < {0}.eta
            AND NOT self.do_not_remove_slow
        "
  - "0 < maximum_eta < {0}.eta"

The following file should mean that each entry on the config file is a single check, multiple entries means OR i.e a torrent will be marked a stale/slow if ANY of it matches.

The above does introduce some issues: 1.1 - Attribute checks within the class itself should become far more difficult; i.e self.recently_queue.get(torrent.hash, torrent.added_on), this would requite a special syntax to be used by the user for example

rules:
  slow:
    - "GET_ADDED_TIME({0})" # Make individual syntax for each special handling
    - "{0}.ADDED_ON" # Make all entries in upper case behave in a way that it returns the appropriate value or the torrent value, if implemented this is likely the best approach.
      - "DO_NOT_REMOVE_SLOW"  # Would return the value of self.do_not_remove_slow

As one can possibly imagine the syntax would have to be restrictive which would make this a not user friendly behaviour as it would expect exact inputs for example python and would have to be special cased to AND and if a user used "and" it would be invalid.

Now onto the actual big issue:

2. How would be user input be translated to code. 2.1 - the simplex option would be an exec call on each rule, I would like to avoid this simplely due to the implications, remote code execution isnt fun and should be avoided where possible - example what if a user accidently run this as a super user and provide an exc that would end up wiping the system files... yes its an edge case but this is an worse case scenario. if this is ever implemented it has to be done so in a contained way so that python code execution can't be performed outside of the

   2.2 - Some sort of mapping would be requite linked the special cased syntax to a behaviour, likely using python operator module and the api return values for qBitTorrent WebAPI in addition to the internal values (This mapping would have to be contantly updated based on new WebAPI version and qBitrr Release.

   3 - How should invalid syntax be handled? ignore that single statement? early exit and don't allow qBitrr to run?

   4 - Is the performance hit on the whole of the script due to new logic having to replace current logic worth while? This would affect even users who don't use this feature.

   5 - At what point should I invalidate support for this behaviour if it is implemented? 5.1 - Flag it as an advance user functionality and provide no support? 5.2 - Make strict WebAPI version and qBitrr versioning requirements for support? i.e Only get support on the latest version of qBitrr and x WebAPI version. 5.3 Try to support it openly and realise how much of a hell that would be only to regreat your decisions?

6 - It would require a non trivial update to the existing logic to allow for custom checks

Summary: 1 - Syntax would be extremely complex 1.1 - It would require an absurd mount of documentation around syntax which I'm not overly keen on 2 - Maintenability would become harder 3 - Performance would be impacted for all users 4 - It would make support a nightmare 5 - It would be a very breaking change requiring a Major update? (Possibly)

I'm not entirely closed off to the idea of it that being said would rather know if there any user interest on this before i commit to it.