Run jobs that take no environment from any runner - #23

This is a second attempt at rust-lang#2269, which had to be reverted shortly
after being deployed, as it caused jobs to fail to run in production.
This commit only differs from that PR in the revision of swirl used.

The cause of the issue was the change in the signature of
`update_downloads`, which does not need anything from the job
environment, and so it only takes a connection. This changed the
environment type for that job from `background_jobs::Environment` to
`()`, so our runner no longer knew how to run that job.

The smallest fix in crates.io would have been to add an unused
environment argument to `update_downloads`. However, having some jobs
not require a shared environment felt common enough that I fixed this in
swirl instead. sgrif/swirl#23 changed the
behavior so jobs with no environment (a.k.a. the environment type is
`()`) are always run, regardless of the environment type of the runner.

Since `update_downloads` is essentially a cron job, and is not enqueued
from the web server directly, this was not caught by our integration
suite. This case was caught quickly after being deployed, and only
affected a non-critical part of the service, so I've opted not to figure
out how to add this to our integration suite.

Update Swirl, take two

This is a second attempt at #2269, which had to be reverted shortly
after being deployed, as it caused jobs to fail to run in production.
This commit only differs from that PR in the revision of swirl used.

The cause of the issue was the change in the signature of
`update_downloads`, which does not need anything from the job
environment, and so it only takes a connection. This changed the
environment type for that job from `background_jobs::Environment` to
`()`, so our runner no longer knew how to run that job.

The smallest fix in crates.io would have been to add an unused
environment argument to `update_downloads`. However, having some jobs
not require a shared environment felt common enough that I fixed this in
swirl instead. sgrif/swirl#23 changed the
behavior so jobs with no environment (a.k.a. the environment type is
`()`) are always run, regardless of the environment type of the runner.

Since `update_downloads` is essentially a cron job, and is not enqueued
from the web server directly, this was not caught by our integration
suite. This case was caught quickly after being deployed, and only
affected a non-critical part of the service, so I've opted not to figure
out how to add this to our integration suite.

r? @jtgeibel