[release/6.0] Avoid not live built packages dependencies that are satisifed by the shared framework in M.E.Logging.Abstractions

[ViktorHofer]

Fixes #59161
Reported by customer via #59158
Regressed with 3897ee5

Customer Impact

Customers who reference the Microsoft.Extensions.Logging.Abstractions package transitively reference the System.Buffers and System.Memory packages when targeting .NETCoreApp even though those libraries are already satisfied by the shared framework.

It's undesirable to have the System.Buffers and System.Memory dependencies in the graph
as these aren't live built anymore and are only serviced on demand (for security issues) from the release/2.1 branch.

Testing

The package built locally doesn't contain the dependencies anymore for net6.0. Also, the runtime local package testing infrastructure restores the produced package and makes sure that all dependencies are satisfied.

Risk

Low. The dependencies are present in the RC1 package and this change just removes them from the net6.0 asset.

[ghost]

Tagging subscribers to this area: @maryamariyan
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixes #59161

The System.Buffers and System.Memory packages are
dependencies of the net6.0 M.E.Logging.Abstractions
library even though these libraries are part of the
.NETCoreApp shared framework.

It's undesirable to have the dependencies in the graph
as these aren't built live anymore and are only serviced
on demand.

Author:	ViktorHofer
Assignees:	ViktorHofer
Labels:	Servicing-consider, area-Extensions-Logging
Milestone:	6.0.0

[ViktorHofer]

@danmoseley I would like to get this into release/6.0 before we snap today.

[ericstj]

Seems reasonable. This is a "regression" from previous release due to 69d6127.

One alternative might be to if-def that change so that we only do it on .NETCore and not downlevel where we take a dependency, that said I'm OK with this change as is.

It is permissible to drop packages from a compatible framework iff:

1. The assembly is already provided by that framework.
2. The assembly provided by that framework will always have a higher version than the package.
3. The assembly provided by that framework will always have all API provided by the package.
4. The assembly provided by the framework provides equivalent functionality.

I believe we can check all these boxes here for both packages.

[ViktorHofer]

Seems reasonable. This is a "regression" from previous release due to 69d6127.

I would prefer to not call that change out as the one that caused the regression. This issue tracks unnecessary added dependencies to the net6.0 dependency group of the package which didn't regress with 69d6127 but with 3897ee5 as at that point the pkgproj infrastructure which stripped these unnecessary dependencies was replaced with NuGet's pack task.

[danmoseley]

Approved. Reduces surface area, which has value when patching, etc. This one might not meet the higher bar tomorrow.