busyTries implementation can cause extremely long wait times

[TanninOne]

On Windows, if busyTries are configured and rimraf encounters an EPERM/ENOTEMPTY/EBUSY error it will retry that call several times, with a bit of a delay.
So far so good. Problem is: Once the tries are used up, it will rethrow that same error to the recursion level further up - which will then also retry.

So imagine you have the directory foo/bar/protected, protected is write protected, you call rimraf('foo') with the default of 3 busy tries.
Effectively this will try to delete foo 3 times, which will try to delete foo/bar 9 times which will try to delete foo/bar/protected 27 times - each attempt being delayed on average by 100ms for a total wait time of almost 4 seconds when it should be 300ms.
Have a directory tree of 6 levels deep and the call takes 2 minutes before it fails - instead of 300ms - and so on.

[isaacs]

I'll have to check if this is still an issue in v4. Seems like it should have a way to tell the parent call that we're giving up now.

[isaacs]

Yep. Fixed it by only retrying if the EBUSY (etc) is raised by the specific thing being deleted.