This is more of an integration test, as it requires the code in the plugin and the code in the custom failure backend to be used as they would be in production to simulate the problem.

First, we set up the failure backend to actually use our custom one (none of the other tests here do that).

Next, we perform the job in a special way that results in failure before `perform` is called (will comment on that method in a moment).

When that's done, we expect:

* 1 processed job (because even failed jobs are considered processed)
* no failed jobs (because the job is scheduled for retry - **this is the thing that happens on master that should not happen**)
* no pending jobs (because the job isn't on a queue, but in the schedule/delayed queue)
* 1 job on the delayed queue (because that's where we expect the job to have gone)

Commenting out the two lines I added to `try_again` causes line 87 to fail, which reveals the problem.