Fix condition in rar v3 code

[Morilli]

• closes Unknown Rar Header: 238 #890

This was an interesting one to track down. Basically, when UnpWriteData is called with a size of 0, it must call writeStream.Write even if destUnpSize is 0 to ensure that Suspended is set to false.
The same condition change must be done here:

sharpcompress/src/SharpCompress/Compressors/Rar/UnpackV1/Unpack.cs

Line 266 in 94789ce

if (destUnpSize < 0)

to make sure that the code passes over both if (destUnpSize < 0) and if (suspended) conditions and continues below.

While investigating this bug I found some other issues in the rarVM code, but I'm not sure how to test them and whether that code is even still used nowadays.

TODO: Find some example archive that shows this bug that isn't 40MB and add a test case for it.

[adamhathcock]

Seems valid to me, not sure what to do to ensure this doesn't happen again. Tests or comments?

[Morilli]

A test would be great but I don't know how to generate an archive that would exhibit this problem, I only used the archive provided in #890 to test this.

I can add a comment to UnpWriteData, however looking at it, the "new" 2017 rar5 code seems to have this same issue, so maybe it needs to be changed there as well?

[adamhathcock]

I'm imagining it has the same issue but I'm not an expert with it

[adamhathcock]

either this PR (or possible the OpenRead) PR has seemingly broke a disposing test on the reader?

[Morilli]

welp, it looks like applying this same diff on the rar5 code breaks it... not very reassuring.