Bad patch generated if new archive contains multiple entries that trigger decompression of one entry in the old archive

[andrewhayden]

If the new archive contains two or more entries that BOTH require uncompression of THE SAME entry in the old archive, two uncompress instructions are generated in the patch stream for the same range. The patch applier expects ranges to be sorted in increasing order, so when it encounters the second range in the stream the offset that it specifies has already been processed and so the patch is treated as invalid.

The fix is to switch from a List to a Set in the PreDiffPlanner; if any entry in the new archive requires decompression of an entry in the old archive, then the old entry should be uncompressed and the instruction should be output exactly once. A new test needs to be added for this case as well.

This didn't come up before because it's a little weird to both clone a resource AND change its compression level at the same time when building a new archive, but it is a valid use case and it is currently broken.

[andrewhayden]

Fixed in 729c0d5