RetryStrategy: AsyncExecChainHandler and ExecChainHandler behavior should be identical

A RetryStrategy is enabled by default in both classic and async.
 
If an exec chain handler is placed after the retry handler, the behavior between async and classic is consistent. The behavior of an Async- and  a classic ExecChainHandler placed before the (Async)HttpRequestRetryExec is different when a retry is actually executed.
 
In case of a retry, the classic HttpRequestRetryExec will split the exec chain and proceed with all handlers configured after itself. Any handler registered before would be called exactly one time with the final outcome of the last retry attempt.
 
The Async version, however, will call any handler registered before itself with every retry. The order of events is counter intuitive as well. All closing events will be emitted after the last attempt.
 
Workaround: In async, ignore all but the first invocation of a handler when the handler is placed before the retry handler.
 
Expected Bahaviour: Both Async and Classic ExecChainHandler behavior should be identical.