WcfExceptionHandler with default configuration leads to 1 second delay in infrequently used channels

[andradf]

When working with a NetTcp binding the defaults and most common usages tend to have the server close inactive channels after some inactivity, usually 10 minutes. This is manifested on the client by throwing an ObjectFaulted or ObjectAborted exception in a subsequent invocation. In scenarios where a channel is used infrequently, we've observed delays of 1-2 seconds due to WcfExceptionHandler using the retry policy provided to ServicePartitionClient to determine a retry wait time. The default retry policy is an exponential with a jitter of 2 seconds plus a base delay of 1 second, even for attempt 0 we get a minimum of 1 second and average of 2 second delays when it should be 0 for these types of errors. And even if we use a custom RetryPolicy instead of exponential , we don't have enough context in RetryDelayParameters to determine if it is being invoked due to an ObjectFaulted/ObjectAborted exception or due to a different transient failure that would justify having the delay (EndpointNotFoundException for example). The ideal solution would be for WcfExceptionHandler to return ExceptionHandlingRetryResult with a wrapper around the retry policy when it's a ObjectFaulted/ObjectAborted that woud return a 0 delay when the retryattempt is 0 or 1.