[Test-Proxy] During recording, re-use existing request body

[scbedd]

Context:

We are seeing an extremely odd behavior during recording of monitor ingestion tests. Specifically the upload of logs.

When running from within the .NET test framework, some of the requests that look this:

[18:45:08] dbug: DebugLogging[0]
      Request URI: [https://<monitorUrl>/dataCollectionRules/dcr-3241746bf36d4042b01e60adc3982153/streams/Custom-MyTableRawData?api-version=2021-11-01-preview]
      Request method: [POST]
      Request headers: [[{"Key":"Accept","Value":["application/json"]},{"Key":"User-Agent","Value":["azsdk-net-Monitor.Ingestion/1.0.0-alpha.20230131.1","(.NET 6.0.13; Microsoft Windows 10.0.22621)"]},{"Key":"Authorization","Value":["Bearer <snip>"]},{"Key":"traceparent","Value":[""]},{"Key":"x-ms-client-request-id","Value":["ec222bca52f1be17a31425a0bb4c9514"]},{"Key":"x-ms-return-client-request-id","Value":["true"]}]]

Randomly 400 with badrequest

[18:45:08] dbug: DebugLogging[0]
      Response Statuscode: [ BadRequest]
      Response Headers: [[{"Key":"Server","Value":["Microsoft-HTTPAPI/2.0"]},{"Key":"Date","Value":["Wed, 01 Feb 2023 02:45:09 GMT"]},{"Key":"Connection","Value":["close"]}]]

@JoshLove-msft is suspicious that gzip may be non-deterministic when compressing/recompressing. Not that the content itself is an issue, but the Content-Length headers WOULD be an issue if this were the case. If the header doesn't match by a couple bytes, its very possible that the service could throw back a 400 bad request at us.

What we'll do here is bypass that issue by merely keeping the original request bytes around and essentially paste them into the upstream request.

I'm somewhat concerned that if it can happen there, why wouldn't it happen during playback as well (where we HAVE to recompress as we need to decompress to sanitize). Worth a try though.

[JoshLove-msft]

I'm somewhat concerned that if it can happen there, why wouldn't it happen during playback as well (where we HAVE to recompress as we need to decompress to sanitize). Worth a try though.

In playback this isn't an issue because the decompressed payload is deterministic. The compressed payload is not.