[release/8.0-staging] Allow setting ZipArchiveEntry general-purpose flag bits

[github-actions]

Backport of #98278 to release/8.0-staging

/cc @carlossanlop @edwardneal

Customer Impact

• Customer reported
• Found internally

Originally reported in dotnet/Open-XML-SDK.

.NET Framework allows consumers of System.IO.Packaging.ZipPackage to use CompressionOption to update bits 1 & 2 in the ZIP archive header's general purpose bitfield. This functionality was lost in .NET Core.

OpenXML is affected because when a document like XSLX is created with our APIs, it is not compliant with the OpenXML specification ISO/IEC 29500-2, as the standard bits 1 and 2 are mandatory and are not reflecting the applied zip compression. Full discussions in #88812 and dotnet/Open-XML-SDK#1443

Specifying the CompressionLevel of System.IO.Compression.ZipArchive will now change these bits, and the ZipArchive's CompressionLevel value will be read from the bitfield.

Regression

• Yes
• No

This PR also introduces a breaking change which is reported in detail here: dotnet/docs#40299 . Summarized, the CompressionOption values from System.IO.Packaging will map to different CompressionLevel levels in System.IO.Compression depending if using .NET Framework or .NET Core.

Testing

New tests were added to both System.IO.Compression and System.IO.Packaging to verify that setting the CompressionLevel sets the expected bits, that they can be re-read correctly and that the file data can still be decompressed correctly.

Risk

Low.

Thanks to @edwardneal for fixing the issue and @maedula for the detailed report of this problem.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-io-compression
See info in area-owners.md if you want to be subscribed.

[carlossanlop]

@ViktorHofer @ericstj can I get a review and a sign-off for this servicing fix, please?

[ericstj]

As discussed offline I'd like to make sure we have a good case for taking this in servicing and that we understand the potential risk. Can we also talk about why this needs to go to both 8.0 and 6.0?

[edwardneal]

The original request for a backport came from dotnet/Open-XML-SDK#1443. Re-reading the issue, I'm not sure whether the request is for the ability to set the compression level bits, the UTF8 bit or both in the general-purpose bitflags, and I've not personally got a strong opinion whether to backport or not. What's your view @maedula?

[carlossanlop]

Closing while we get clarity on whether this bug's impact is severe enough to justify a backport.

[maedula]

The original request for a backport came from dotnet/Open-XML-SDK#1443. Re-reading the issue, I'm not sure whether the request is for the ability to set the compression level bits, the UTF8 bit or both in the general-purpose bitflags, and I've not personally got a strong opinion whether to backport or not. What's your view @maedula?

@edwardneal The initial issue was about bit 11 (UTF8) being toggled and thus not being spec compliant. I consider this as a no-go and Open-XML-SDK should produce spec compliant results regardless of the .net core version. But I guess I do not understand the concern about the breaking change vs. not being spec compliant in the first place.

I personally consider the compression level bits as a rather cosmetic issue and inconsistent to what the SDK produces using .net framework.

[edwardneal]

That makes perfect sense. It looks like we can leave this PR alone then - the actual PRs we care about are #87883 and #88978, which would need to be backported to .NET 6.0.