BundleMaker copy fix

[Graeme-Miller]

When cloning a zip, we were using the ZipEntry from the input zip.
This causes issues, as the info in the input ZipEntry is not necessarily correct for the output zip.
Specifically, compressed size can be different. This causes exceptions when the wrong amount of bytes are written.

This change means that a new ZipEntry is created, and the info from the input ZipEntry is ignored.

[m4rkmckenna]

@Graeme-Miller Can you provide steps to re-produce ... does this happen for every uploaded zip?

[drigodwin]

Does it matter that we will lose all the information from ZipEntry apart from the file name?

[Graeme-Miller]

Can you provide steps to re-produce
@m4rkmckenna quickest way to replicate is to use the brooklyn cli from here: apache/brooklyn-client#44. Using that CLI, zip up a folder and send it to a standard brooklyn.

Even though go creates the zip correctly, brooklyn is unable to copy it due to a mismatch between the amount of compressed bytes the zipfile created by go is reporting, and the zipfile created by java is reporting. This is likely due a difference between the algorithms go and java use.

does this happen for every uploaded zip
No, as long as the same algorithm and compression level is used this should not happen. I have yet to be able to recreate this with anything other than the zip created by go (which leads me to believe google are using a different, smarter algorithm)

[Graeme-Miller]

@drigodwin no, it doesn't. If we were creating a zip from scratch we would do what I have done here, and create a zip entry with only the name. The zip code would then figure out the rest.

We should be doing exactly the same thing for copying a zip, i.e. we should not pre-set what we think the compressed size, and other info are going to be.

[m4rkmckenna]

LGTM