[release/6.0] Enforce HttpClient limits on GetFromJsonAsync

[MihaZupan]

Backport of a minimized change of #79386 to release/6.0

Customer Impact

HttpClient has two properties users can tweak to limit the amount of time and resources spent on a given request (Timeout and MaxResponseContentBufferSize).
GetFromJsonAsync is inconsistent in the enforcement of these limits compared to other helpers (GetStringAsync, GetByteArrayAsync, and DeleteFromJsonAsync).

There are three main ways to get the response content from HttpClient:

1. Using the one-line helper methods

   await client.GetStringAsync("foo");            // Limits enforced
   await client.GetFromJsonAsync<MyClass>("foo"); // Limits **NOT** enforced

2. Get the response object and call helpers on its content

   using HttpResponseMessage response = await client.SendAsync(request);
   await response.Content.ReadAsStringAsync();          // Limits enforced
   await response.Content.ReadFromJsonAsync<MyClass>(); // Limits enforced

3. Optionally use ResponseHeadersRead, asking the client not to buffer the response content as part of the SendAsync call

   using HttpResponseMessage response = await client.SendAsync(request, HttpCompletionOption.ResponseHeadersRead);
   await response.Content.ReadAsStringAsync();          // Limits not enforced by design
   await response.Content.ReadFromJsonAsync<MyClass>(); // Limits not enforced by design

This PR changes the behavior of the client.GetFromJsonAsync helper to match that of GetStringAsync and friends (case 1).
This allows us to present consistent HttpClient behavior across the board.

Testing

I added targeted CI tests that confirm limits are consistently enforced.

Risk

The enforcement of limits means that some requests that would previously succeed may now fail (either time out or exceed the size limit). It is unlikely that anyone is knowingly relying on this behavior given the inconsistencies mentioned above.
The default limits are also very large (100 seconds and 2 GB of content), so for a request to hit them, the user has most likely lowered them manually, indicating the intent that they do want them to be enforced. It also means that if they do run into issues, they can tweak the existing settings directly.

The change can also result in slightly higher memory consumption as we're buffering the whole body before we start the deserialization process. We do not expect this to be meaningfully impactful.

[ghost]

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

Issue Details

---

Backport of a minimized change of #79386 to release/6.0

Customer Impact

TODO

Testing

TODO

Risk

TODO

Author:	MihaZupan
Assignees:	MihaZupan
Labels:	area-System.Net.Http
Milestone:	6.0.x

[carlossanlop]

Last day to merge backports for the February Release is tomorrow. Please fill out the template, make sure to mention the customer impact. Add the servicing-release label, and send email to Tactics requesting approval.

[carlossanlop]

Talked to @MihaZupan. This will go in next month.

[ManickaP]

Thanks!

[MihaZupan]

Failures are #81391, #81544.

[carlossanlop]

Hey @ViktorHofer what should we do about this failure?:

.dotnet\sdk\6.0.113\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.EolTargetFrameworks.targets(28,5):
error NETSDK1138: (NETCORE_ENGINEERING_TELEMETRY=Build)
The target framework 'net5.0' is out of support and will not receive security updates in the future.
Please refer to https://aka.ms/dotnet-core-support for more information about the support policy.

[ViktorHofer]

That's happening because of dotnet/sdk@4c7675d. Apparently serviced SDKs now also warn about a TFM that moves out of support, even when that's long after the stable SDK itself shipped originally.

We still produce net5.0 assets in our release/6.0 branch and we don't want to stop doing that. So we need an escape switch =>/p:CheckEolTargetFramework=false.

You can suppress that error by setting <CheckEolTargetFramework>false</CheckEolTargetFramework> here:

runtime/src/libraries/testPackages/build/Directory.Build.props

Line 5 in bd54093

</PropertyGroup>

[karelz]

Approved by Tactics via email by @SteveMCarroll on 2/9.
Adding Servicing-approved label to the PR.

[carlossanlop]

Approved by Tactics for 6.0.15.
Signed-off by area owners.
CI failures unrelated and have fixes merged to the branch: #81544 #81391 #81848
Required OOB changes look good.
Ready to merge.