There is a race-condition in JesqueSchedulerService#acquireJobs which seems to be caused if the scheduler threads have different latencys to the redis instance.

So 2 threads are getting the same job from Trigger.TRIGGER_NEXTFIRE_INDEX.
Since we only call watch after that, if one server is so fast that it called watch and executed the transaction, the other thread may not have called watch yet and so doesn't see that the fast thread already aquired and executed the job. The slow thread then calls watch and executes his transaction, causing the scheduled job to be enqueued a second time.

This patch fixes this issue by comparing jobData.score and trigger.nextFireTime.millis after we've called watch.
The fast thread will have updated the trigger.nextFireTime so that it's now different from the jobData.score that we've read before calling watch.

Fixes #29