Avoid iteration for stopping race condition

[etiennebarrie]

Follow-up to #515

First, we can entirely avoid the "optimistic update" if the run is already stopping, like we were doing before in the non-race-condition case.
Also, since we know whether or not the record was updated, we know it was indeed stopping (but not its actual status), so we can prevent even a single iteration from happening (but we have to reload to get the actual status to either moved to paused or cancelled).

I tested the first point by re-using count_uncached_queries.
For the second point, I tested it by simulating a race condition for the model, but I also added a test at the job level for good measure. It also causes the race condition by running in a before_perform callback. This runs after Active Job deserializing the Run, but since it's prepended, before TaskJobConcern#before_perform, when we do the optimistic update.

[adrianna-chang-shopify]

Test name is a little unclear, maybe:

Suggested change

	test ".perform_now skips iterations when Run is cancelled even when a race condition happens" do
	test ".perform_now avoids iterating and cancels Run when race occurs between starting and cancelling a Run" do

?

[etiennebarrie]

Right, I used that with symmetry with the previous test. Updated both.

[adrianna-chang-shopify]

Do we need to assign run = @run? Can't we just use

CustomTaskJob.race_condition_hook = -> do
  Run.find(@run.id).update(status: :cancelling)
end

?

[etiennebarrie]

Good catch, I needed that before because I used before_perform directly.