Lack of retries control in AbstractMessageHandler

In AbstractMessageHandler whe have some retry mechanism, but the current implementation contains one drawback: after failing processing of the message we abandon the one and in this case we can't control repeated consumption and there is high chance that message will be received immediate.

We are doing the thread sleep for exponential backoff behavior, but it is innaficient because thread appears busy during the sleeping time. On the other hand, we unable to control max delivery count from the code, because it is an attribute of the topic subscribtion, not our services.

Also there is a new reindex into the indexer service process which locks the particular kind during the re-indexing and this process can be really long running (hours). In this case all events for the locked kind will toward to the dead letter queue, if we don't have long term retry mechanism.

It would be good if we could have more control for retry behavior using service bus client infrastructure principally.