Support adding filter parameters to api calls

[leviable]

The TestRail API supports adding parameters to the endpoint URL to filter results returned. For instance, the get_runs endpoint (http://docs.gurock.com/testrail-api2/reference-runs#get_runs) supports the following URL parameters:

:created_after  timestamp   Only return test runs created after this date (as UNIX timestamp).
:created_before timestamp   Only return test runs created before this date (as UNIX timestamp).
:created_by int (list)  A comma-separated list of creators (user IDs) to filter by.
:is_completed   bool    1 to return completed test runs only. 0 to return active test runs only.
:limit/:offset  int Limit the result to :limit test runs. Use :offset to skip records.
:milestone_id   int (list)  A comma-separated list of milestone IDs to filter by.
:suite_id   int (list)  A comma-separated list of test suite IDs to filter by.

Add a filtering mechanism that allows the user to request filtered results from the API.

[travispavek]

Copy/Paste of comments left in PR #25 on this subject.

I am open to adding params to the API calls, however I feel that a Filter class is overkill/unneeded and maybe even a little confusing. We could just add the appropriate query params as arguments to the function.

This will however also mess with the cache. It was easy to say give me all runs and cache them. Now you are saying give me only runs with start date x and end date y. If there is a way to get all results I still prefer that and then filter later on the cache.

[travispavek]

I take back my preference on getting all items. This is great for small projects but over time you may be pulling hundreds of thousands of runs. We need to put some thought into how to design this.

[travispavek]

A quick glance it looks like runs may be he only one that can ballon in size over time. Maybe we just need to handle this case specially.

[leviable]

I think test plans and test cases also face that problem, potentially. For instance, I'm planning to stand up a CI testing environment where each CI check would create a test plan, then add one test run to the test plan for each language our website supports. Over time that would be a lot of test plans. Likewise, I could easily see a scenario where a test suite has more than 250 test cases.

What if we roll our own pagination support? If the result objects total 250, get the date of the oldest object, and repeat the api call with the date as the end_date?

objs = list()
end_date = None
while True:
    resp = get_resp(end_date)
    objs += resp
    if resp == 250:
        resp.sorted(key=lambda x: x.id)
        end_date = resp[-1].created_on
    else:
        break