Move the Password property from DeflaterOutputStream into ZipOutputStream

[Numpsy]

refs #590

This would be a breaking API change, but - is there actually a need for the Password property to be on DeflaterOutputStream, given that it only applies to creating encrypted Zip files? (the property isn't actually referenced by DeflaterOutputStream anyway, only from ZipOutputStream)

Related:
The InitializePassword and InitializeAESPassword functions in DeflaterOutputStream only seem to be called from ZipOutputStream as well, though they set the (presently private) cryptoTransform_ member as well, so moving them as well would need a further change.

I certify that I own, and have sufficient rights to contribute, all source code and related material intended to be compiled or integrated with the source code for the SharpZipLib open source product (the "Contribution"). My Contribution is licensed under the MIT License.

[codecov]

Codecov Report

Merging #604 (c15cb91) into master (d9fb8a4) will increase coverage by 0.06%.
The diff coverage is 93.75%.

@@            Coverage Diff             @@
##           master     #604      +/-   ##
==========================================
+ Coverage   73.24%   73.30%   +0.06%     
==========================================
  Files          68       68              
  Lines        8712     8710       -2     
==========================================
+ Hits         6381     6385       +4     
+ Misses       2331     2325       -6     

Impacted Files	Coverage Δ
...ib/Zip/Compression/Streams/DeflaterOutputStream.cs	85.36% <ø> (-0.64%)	⬇️
src/ICSharpCode.SharpZipLib/Zip/ZipOutputStream.cs	92.19% <93.75%> (+0.07%)	⬆️
...Code.SharpZipLib/Zip/Compression/DeflaterEngine.cs	87.45% <0.00%> (+0.33%)	⬆️
...ICSharpCode.SharpZipLib/BZip2/BZip2OutputStream.cs	79.19% <0.00%> (+0.44%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d9fb8a4...c15cb91. Read the comment docs.

[Numpsy]

@piksel would you consider the public API change as acceptable, before I see about doing anything else with this?

[piksel]

Yeah, I think it's good idea. It's a breaking change on a technical level, but if there is any code out there relying on it, it's probably not doing what the author intended anyway (as shown by the referenced issue).

[Numpsy]

hmm, moved the code that sets up the crypto transforms and didn't notice till looking at the coverage results that the existing code initialises the static _aesRnd member where it's declared and also checks it for null and tries to set it up where it's used, can have a look at tidying that up as well.

[piksel]

Will still push this to v1.4.0 due to the "breakage".