refactor(filters): checkMaxDownloads

[frrad]

Just some minor style thing I ran into while researching autobrr/autobrr.com#147 feel free to ignore if you don't like it.

Two related questions:

1. That comment on L264 - why do we return early? All the other possible rejections just add to the list and rely on the if len(...) >0 at the end. I thought that was mysterious.
2. Also curious about the "current time period" approach as opposed to a lookback window from now. I was thinking about adding a comment here https://github.com/autobrr/autobrr/blob/develop/internal/database/filter.go#L1416 about what the SQL queries are doing, sort of analogous to more explanation for "max per" autobrr.com#147. Would be interested in adding the rationale in the comment too.

[zze0s]

This is indeed a bit more clean.

1. We return early because there's no point IMO to process further since no other check will change the decision.
2. It could for sure use some better comments there. We modeled this like autodl-irssi did and there it was "time window" from start of the unit. It was rolling in the beginning because of bugs. I think it would be confusing and would lead to weird results.

The plan for later down the road is to build a more robust schedule where you can set it per hour similar to this in Deluge: