Ensure that CommitDelayIncrement is greater than TimeSpan.Zero

[hazel-bohon]

• Fixes If CommitDelayIncrement is set to zero, the Outbox dispatch message the MaximumCommitDuration is never reached #530
• Added a check to ensure that the value of CommitDelayIncrement is greater than TimeSpan.Zero.
• Added unit test to verify the behavior.

[hazel-bohon]

Some alternatives that reviewers might think about:

1. Imposing a floor value on the property such as TimeSpan.FromTicks(1) (the absolute minimum value greater than zero), or anything up to the current default of TimeSpan.FromSeconds(2).
2. Updating this so that it will be able to handle the case where the value is TimeSpan.Zero

   NServiceBus.TransactionalSession/src/NServiceBus.TransactionalSession/TransactionalSessionDelayControlMessageBehavior.cs

   Line 45 in c00d617

   var newCommitDelay = commitDelayIncrement.Add(commitDelayIncrement);

   We could accomplish this by either adding a second check that will cause it to timeout after a certain number of maximum attempts, etc.

[mnadareski-particular]

The change here directly addresses the issues that were being seen.

I was looking into how and where this value actually ends up being used to see if this fix would be sufficient for any underlying issues. I ran across https://github.com/Particular/NServiceBus/blob/master/src/NServiceBus.Core/DelayedDelivery/DelayDeliveryWith.cs which only checks that it's not less than zero. I'm wondering if other places that cascade out could also have these issues hidden.

Also maybe not relevant for this PR, but I think it would be interesting to see why a duration of 0 was actually causing issues internally.

Edit: After looking at the alternate proposed solution, it makes a lot more sense why the value of 0 would be problematic coming from this context. The point above about DelayDeliveryWith still stands.

[danielmarbach]

Nice find!

Past me thinking: Sure, we can just ship without validation, and it will be fine.