Remove zlib from .NET 9 Runtime Deps images

[lbussell]

Fixes #5687

16b1b3c is not the best solution to excluding zlib packages for .NET 9. I'm working on a better solution to all of the hardcoded package lists in ProductImageTests.cs. However it may be better to do that in a follow-up PR.

[richlander]

@carlossanlop @jkotas here is the E2E of the zlib change.

[carlossanlop]

@lbussell just wanted to share here that we will still need the system-installed zlib package in the following platforms: armv6, android, ios, tvos and maccatalyst.

We decide that in cmake using this variable: https://github.com/dotnet/runtime/blob/4d2d3d3ef5870483af9e821b3f315d1dcd8b1e7d/eng/native/configureplatform.cmake#L511-L516

And we find the system-installed package using this logic: https://github.com/dotnet/runtime/blob/4d2d3d3ef5870483af9e821b3f315d1dcd8b1e7d/src/native/libs/System.IO.Compression.Native/extra_libs.cmake#L6-L11

[lbussell]

@lbussell just wanted to share here that we will still need the system-installed zlib package in the following platforms: armv6, android, ios, tvos and maccatalyst.

@carlossanlop We don't ship containers for any of those platforms, so we should be good 👍

Will we need system zlib for any SDK scenarios? Our tests seem OK but I want to make sure I'm not missing anything. It's likely that most or all of our SDK base images include system zlib by default. If that's the case we'd want to install it explicitly as a dependency so it can be updated for security releases.

[carlossanlop]

Will we need system zlib for any SDK scenarios?

I'm unfamiliar with the requirements/needs of the sdk repo. My naive assumption is that we would need the same requirements as runtime, but I'd rather confirm with someone more familiar with that repo.

@jkoritzinsky or @akoeplinger do you have an answer for this?

[jkotas]

The SDK itself is a pure managed code. It should not have any direct dependencies on zlib.

Some tools or packages outside of SDK may have dependencies on zlib. If there are any tools or packages like that, I would say that it is a problem for those tools or packages to address. It does not make sense for us to carry unmanaged dependencies for them.

[richlander]

Our lack of (package) dependency on zlib has also been documented now.

https://github.com/dotnet/core/blob/main/release-notes/9.0/os-packages.md

Fine question @carlossanlop. I think there is no reason to wait on merging.