Fix nightly test failures for Go SDK

[mgyucht]

Changes

The latest refactor of the client code in the Go SDK caused several regressions:

1. API calls using content-type: application/json apparently don't support transfer-encoding: chunked. To address this, I rewrite the internals of client.go to explicitly not wrap the bytes.NewReader or strings.NewReader in io.NopCloser. net/http's Client checks whether the body is a byte or string reader explicitly in order to set content-length and not use the chunked encoding.
2. UC API deletes that previously required query parameters in the body are not correctly serialized. However, the underlying issue has been fixed upstream, so we can remove all of this custom serialization code now.
3. Previously, the application/json Content-Type was sent with every request. However, there are some requests that have no request body, and as a result, that header was not being set on the request anymore. This conflicts with the Go SDK's implementation that always serializes the request object and adds it to the request body. Some services tolerate a request body without Content-Type, others do not. In this change, we pass nil for request if there is a request body or if there are request query parameters in the request structure (only for GET and DELETE). This involves one small OpenAPI change: exposing the underlying OpenAPI operation to see if there is a request body defined.
4. After changing the request body to use io.Reader, the reader is consumed during httpClient.Do(). If the client needs to retry, the request body is not reset, causing the retried request to have an empty body. We refactor the request body implementation to support resetting. As part of this, I made a number of changes to the error handling to clarify method behaviors and consolidate common functionality into simple functions.
5. Currently, we specify that the input for streaming bodies must be an io.ReadCloser. This isn't strictly the case: we can accept io.Reader as well, as the HTTP client will never close the request body. This does make it slightly more verbose for users: if they have an io.Reader that they want to use with a streaming body, they need to wrap it in io.NopCloser(). This PR separates the types for request and response body logic so that, internally, io.Reader is used for requests and io.ReadCloser for responses. This is not propagated to the generated parts of the SDK directly yet, as that would require a more invasive change (which may not be possible with our OpenAPI model), but at least it should allow us to handle requests and responses appropriately within the client.

Additionally, the name of the field of the response in streaming response bodies should be capitalized, so we must use PascalCase instead of CamelCase.

Finally, I've made small changes to error messages to better indicate where errors were happening within the client, so tests that matched on error messages exactly have changed.

Tests

Integration tests are passing.

• make test passing
• make fmt applied
• relevant integration tests applied

[codecov-commenter]

Codecov Report

Patch coverage: 90.90% and project coverage change: +0.04% 🎉

Comparison is base (6a8a0ab) 16.72% compared to head (cb1f0d7) 16.76%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #592      +/-   ##
==========================================
+ Coverage   16.72%   16.76%   +0.04%     
==========================================
  Files          85       85              
  Lines       11198    11181      -17     
==========================================
+ Hits         1873     1875       +2     
+ Misses       9154     9137      -17     
+ Partials      171      169       -2     

Files Changed	Coverage Δ
client/client.go	84.95% <90.90%> (+6.76%)	⬆️

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tanmay-db]

I was thinking on how we can prevent such regressions, were the integrations tests ran over the changes that caused regressions or they the tests passing before?

[mgyucht]

Yeah, that's my bad. The integration tests were failing on this PR. A unit test for this case would be too deeply connected to the HTTP library (ensure that application/json requests are never chunked). IMO this is OK: as long as we block releases on integration tests passing, I think this isn't a horrible outcome for this project.

[mgyucht]

use io.Seeker

[mgyucht]

%T

[mgyucht]

maybe use requestBody as receiver instead of *requestBody

[mgyucht]

Add test for this pathway

[tanmay-db]

Thanks for going over the PR. LGTM