Fix thread-safe comparison used to optimize circuit breaker's Success method

[DavidBoike]

The circuit breaker's Success() method must be as close to a no-op as possible on the happy path, but when disarming in a multi-threaded environment still needs to run the disarm logic only once.

Previously, while querying values was done in a thread-safe way, a thread on the Failure method could pause while a Success() call ran to entirety, setting the failure count to 0, and ensuring that further calls to Success() would see a failure count of 0 and take no action, even though the arming action had been executed most recently.

This resulted in a scenario where no number of Success calls could undo the armedAction, unless another Failure call went first.

[awright18]

This seems like it would solve both problems.

//if there have been no failures previously then return
if(Interlocked.Read(ref failureCount) == 0 )
{
	return;
}
else //if there were previous failures then it's ok to disarm now.
{
   if(Interlocked.Read(ref failureCount) > 0) //not sure if this check is necessary or not.
   {
	  Interlocked.Exchange(ref failureCount, 0);
   }
}

[danielmarbach]

Here is a hopefully simplified version #1057

[DavidBoike]

Closing in favor of #1057