Add property-based testing for query filtering

[gregbrowndev]

The find all jobs API, GET /api/jobs, takes a set of 7 filters. The core jobs service unit test and e2e test needs more coverage of this functionality. We need to use property-based testing to try all the possibilities. We need to generate a large enough dataset and write an interpreter to persist this data into the application. Fortunately, the data model is simple, as there is only a single Job table with no foreign keys. This means we can generate a list of jobs without managing dependencies with other jobs.

Because the core JobService handles the find query, unit testing this with property-based testing has little value as we'd just be testing the fake in-memory implementation. To test the query logic, we'd have to property-based test the e2e test of the REST API. Now is a good time to iterate on the architecture and refactor queries into a separate QueryService that does direct SQL queries to the DB. This will remove the wasted effort of duplicating and testing the query logic on the fake repository. This issue is tracked here: #65.

For now, however, just property-based test the LiveJobRepository and keep the JobService unit test and JobRoutes e2e test lightweight. This is much simpler as the integration test can cleanly roll back the transaction after each test.

Requirements:

• Add property-based testing to test the LiveJobRepository find method