Feat; Split request job into benchmark jobs

[Jamesbarford]

Adds the database table job_queue along with creating a BenchmarkJob from a BenchmarkRequest.

This does not include enqueuing a parent if there is a missing backend/profile.

[Kobzol]

Thanks for the changes, left a few other thoughts.

I'd like to remove BenchmarkJob::create_queued, because it creates the wrong incentives - it shouldn't be usable in "normal" code, because everything should go through the DB, and it ideally shouldn't be usable in tests, because then we test something that doesn't actually happen in production - even the tests should go through the DB if possible. This is a bit different from the benchmark request, where it made sense to create it in code and then insert it into the DB, because we had several variations of the request that could exist. But the job is more specialized, and it doesn't make sense to create it outside of the database.

It would also be nice to add at least some brief doc comments in code on top of the job, just to explain what is it for.

[Kobzol]

Thanks! I tested this locally and noticed that multiple requests were marked as in progress, because the enqueuing loop didn't end after enqueuing the first request. I fixed that and added more logging, which helped me with debugging locally.

Btw you can run local Postgres DB, run the website with the CRON environment variables and it will actually start creating the master/release artifacts and enqueuing jobs, so it can be easily tested.

[Kobzol]

Before we go for marking requests as complete, we should work on the collector side, as that's the next functionality in the request/job lifecycle. So there should be a new collector command, something similar to BenchNext, which will:

• Receive the name of the collector
• Load the collector config from the DB and update the heartbeat (could we actually do that with a single SQL query? :) )
• Dequeue a job

I'd end there, because I still need to reland #2161 before we move forward there. I will work on that next.