Improve performance of job page

[danielplohmann]

The jobs page is currently very slow when having a large queue. One reason for this is certainly that the queue is barely using any indices on fields but also that rendering the page carries out multiple full collection scans and data retrievals as JobResource is doing the start/limit and filtering instead of having the database/MongoDB do this efficiently.

In order to improve performance for this,

• the jobs page could be split up into multiple pages per Job type (Matching, Query, Blocks, Other)
• start/limits could be performed efficiently on the DB
• cleanup functionality for the queue should be exposed to the front-end (related to #38)

[danielplohmann]

commit 435dc22 should now provide the foundation to address several of these things in the frontend.

[danielplohmann]

As a first step, this has now been integrated in v1.2.8, and should provide much better performance. Looks like this:

The next step would be an extension with filtering for lists of sample_id and family_id (for rapid selection in the sample table) and exposing queue deletion functionality in the frontend. @yankovs feel free to test if the job page is more responsive now for your collection.

[yankovs]

Wow, this looks amazing! Great job :)

Our huge MCRIT instance is unfortunately down in favor of a slimmer one with much less samples. But i'll still test it out, maybe even on a local instance with lots of samples.