Do not retry already failed files when restoring transfer from journal context

[MarcinKowal]

Which service(blob, file) does this issue concern?

File, Blob

Which version of the SDK was used?

2.0.0.3

On which platform were you using? (.Net Framework version or .Net Core version, and OS version)

Windows .net 4.6.2 and Linux .net Core 3.0

How can the problem be reproduced? It'd be better if the code caused the problem can be shared.

1. Create transfer instance from journal stream using DirectoryContext.
2. Try to transfer directory to blob or fileshare with some files including at least one file that will fail. You can cancel the transfer after failed file was reported or wait to the end.
3. Recreate transfer from existing context and execute it once again. Failed file will be retried.

This is existing behavior and works fine but I'm wondering is there any way to instruct recreated transfer to not retry already failed paths.

What problem was encountered?

We're using UploadDirectory to transfer big amount of data to blob and fileshare instances. Due to i.e. expiring token transfer may fail, which is completely fine but we handle given scenario on our business logic and restore transfer from existing journal file stream. So the reason why transfer initially failed was hidden from the user and transfer is being internally retried.

The issue is that when there were failed files reported by DMLib and transfer was restored from context, all already reported failed files will be retried and also reported once again either as a success or still as a failure.
This is quite confusing as given file path could be reported multiple times.

Have you found a mitigation/solution?

Could you expose a flag to TransferContext to indicate that if it is recreated from existing journal, all already processed paths will not be retried. To be backward compatible by default failed files will be transferred once again, but when given flag is set only files that were not processed are being transferred.