Partially enable job queue in production

[Kobzol]

I think that we have ~3 ways of testing the new job queue:

1. Run both the old system and the job queue in parallel, but run the job queue collector in "dry run" mode, i.e. do not store anything in the DB
2. Run both the old system and the job queue in parallel, but only use the job queue for try builds on a specific PR, and do not enqueue parent jobs, so that we only use the job queue for one PR and nothing else
3. Stop the old system and test the job queue in production while it is stopped

This PR implements 2). While 1) would allow us to test more things, it would require non-trivial changes to the collector, and it would also fill the job queue and the benchmark requests table with a lot of data that we would then have to get rid of. So 2) seemed like the easiest option for now.

The commented code is temporary, of course.

My goal is to see what kind of interesting situations we run into when we merge this PR and start a few try builds on rust-lang/rust#147039. It should also help us figure out the things that we should be logging in the cron job.

[Jamesbarford]

Bar the test suite failing, this looks like a good idea to me 👍 . From my manual testing this should work.

[Kobzol]

Let's see.