[release/7.0] Enforce HttpClient limits on GetFromJsonAsync

[MihaZupan]

Backport of a minimized change of #79386 to release/7.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 change 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/7.0

Customer Impact

TODO

Testing

TODO

Risk

TODO

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

[carlossanlop]

Tomorrow is the last day for merging backports for the February Release. Can you please fill out the template, making sure the customer impact is clearly described, add the servicing-consider label, and send an email to Tactics requesting approval?

Also, there are networking-related CI failures. Can you please investigate them?

[MihaZupan]

Build failure is known according to build analysis.

[carlossanlop]

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

[ManickaP]

Thanks!

[karelz]

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

[carlossanlop]

Approved by Tactics for 7.0.4.
Signed-off by area owners.
CI failure was a timeout cancellation in staging.
Required OOB package changes look good in System.Net.Http.Json.
Ready to merge.

[carlossanlop]

@MihaZupan @ManickaP I'm looking at the rolling builds for the release/7.0 branch, and after merging this PR, I am seeing a nuget issue related to System.Net.Http.Json:

https://github.com/dotnet/runtime/runs/11233952875

Can you please take a look? I'll open an issue to track this. It needs to get fixed before Monday EOD. That's the day we close the servicing branches.

Edit: I opened #81914 and pinged Viktor/Eric for help.