Usability issue with error handling implementations of HandlerChainPolicy

[mkmurray]

Custom error policies for FT are currently done today by creating a HandlerChainPolicy. It allows you to do things like this:

public class ICommandChainsErrorHandlingPolicy : HandlerChainPolicy
{
    public override void Configure(HandlerChain chain)
    {
        chain.MaximumAttempts = 10;
        chain.OnException<ConcurrencyException>().Retry();
        chain.OnException<TimeoutException>().Retry();
    }

    public override bool Matches(HandlerChain chain)
    {
        return chain.InputType().CanBeCastTo<ICommand>();
    }
}

However, @jeremydmiller admitted he hadn't thought of the use case where you would have multiple error handling policies each with their own Matches implementation. I had another error handling policy after this one that applied to all chains and ended up stomping on this first one, changing the MaximumAttempts value back down to 5.

Jeremy asked that I start this issue to discuss how to make this API more clear. Perhaps we only allow one ErrorPolicy, or make it a setter instead of a method. With that, I can see where I would want different MaximumAttempts retry counts depending on the Exception, not just chain wide.

For now, I'm going to either combine my two policies into one if possible, or at least make the two of them smarter and in the right order so that nothing is stomped over.