Jadu::Claim.create submits claims to Jadu.

Jadu::Claim.create is just a wrapper around the work of others
so the specs just assert the relevant methods are called on
the collaborator objects. I don't like testing with a lot of
doubles because it's brittle, but I also don't like duplicating
tests already extant. I have attended to the brittleness risk
by using instance_doubles with check the doubled object responds
to mocked methods.
Do we think this is the right thing to do here? Raising an exception I expect would kill the worker, which would prevent the job from sending an ACK to RabbitMQ. The Sneakers adapter doesn't explicitly support retrying jobs but this would achieve the same thing because RabbitMQ knows that if a worker dies without sending an ACK it should keep the message and send it to another worker.

The alternative would be to do something like this in the production setup:

```ruby
class ActiveJob::Base
  around_perform do |job, block|
    begin
      block.call
    rescue
      requeue!
    end
end
```

This of course means we're leaking AMQP specific stuff into what is supposed to be an abstract interface (ActiveJob)