Feat: Logic for finding the next request to be processed and tests

[Jamesbarford]

Tees up the next request in the benchmark_request table (does not create jobs in what will be the job_queue table.

• Tests for database
• Tests for the sorting
  • On sorting; I did implement the sorting logic in SQL - it's probably more performant however it's about 60ish lines and would be fairly difficult to maintain. As we shouldn't be pull back vast amounts of data, and we only do this when something is not in_progress I think we should be ok? Though I can bring back the SQL version if needed.
• I couldn't see an obvious path for stubbing out some of the fields on SiteCtxt thus split the sorting logic to; get_next_benchmark_request(...)
• We want to rename waiting_for_parent, I'm a bit lost as to what the name should be so am very open to suggestions. waiting along with some code comments about what waiting means for the different types of commits was the best I could think of however I held off

[Kobzol]

Left a few comments, but it would be best to discuss in sync I think.

[Kobzol]

I think we can discuss the sorting logic in sync, now that we can take a look at existing code.

[Kobzol]

Left a few comments, but it looks pretty closely to how I envisioned it. I was a bit confused by the comments about "30 days" in tests though.

[Kobzol]

Thank you! Please squash the commits and we can merge this.

[Kobzol]

Thanks!