What kind of change does this PR introduce?

Fixes issue #1384 by ensuring response content is loaded to a buffer before attempting serialization.

What is the current behavior?

When an exception is thrown during deserialization, ApiException attempts to capture the request content to the Content property to make it available when the exception is being handled (e.g. so apps can log the content to aid debugging). However, the underlying stream in the HttpContent object has already been consumed by the deserialization and cannot be re-read.

What is the new behavior?

By loading the content to a buffer before attempting to deserialize we ensure the stream can be re-read by ApiException.

What might this PR break?

I've moved the LoadIntoBufferAsync call to just before the call to the (de)serializer to ensure we only do this on this exact code path, rather than as soon as the content variable is set as I originally suggested in #1384. This should avoid any problems that could arise from API calls that expect to handle the HttpContent or Stream directly (calling LoadIntoBufferAsync is probably not desirable for these scenarios where we might expect endpoints to return long-lived connections or very large payloads).

Please check if the PR fulfills these requirements

• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

Other information: