[Golang] In case of HTTP error, response body is inaccessible

Description

When a swagger-generated go client performs a request and gets some sort of HTTP error (HTTP response code >= 300), the response body is read and placed in the returned error string.

This prevents any later access to the response body.

Swagger-codegen version

2.3.1

Swagger declaration file content or url

https://github.com/giantswarm/gsclientgen/blob/swagger-codegen-2.3.1/api-spec/oai-spec.yaml

Command line used for generation

https://github.com/giantswarm/gsclientgen/blob/swagger-codegen-2.3.1/Makefile#L7-L14

Steps to reproduce

The API I am trying to consume has a difference in the response body structure in case of HTTP success than it has in case of an error.

Example for success:

HTTP/1.1 200 OK
{
  "general": {...},
  "workers": {...}
}

Example for a bad request:

HTTP/1.1 200 OK
{
  "code": "BAD_ARGUMENT",
  "workers": "The URL parameter 'num' must not be zero"
}

In order to get the details about the error (code and message) I need to obtain the response body JSON and parse/unmarshal it in my own function.

Unfortunately, the body is no longer accessible at that point (from source):

        defer localVarHttpResponse.Body.Close()
	if localVarHttpResponse.StatusCode >= 300 {
		bodyBytes, _ := ioutil.ReadAll(localVarHttpResponse.Body)
		return successPayload, localVarHttpResponse, reportError("Status: %v, Body: %s", localVarHttpResponse.Status, bodyBytes)
	}

The fact that the body has been read once means that it cannot be read again. An attempt to do so yields an error

http: read on closed response body

I'll add that I think the error returned should not contain the response body. For example, if the error response is large, this may totally obscure any logs the error is written to.

Related issues/PRs

https://github.com/swagger-api/swagger-codegen/pull/7810

Suggest a fix/enhancement

Do not read the response body in case of an HTTP error, thus leave handling of the error response body to the caller.

Start with the generated default_api.go code around the HTTP error handling shown in the issue, then trace that code back to the generator template. Verify the behavior with a client request returning an HTTP status of 300 or higher; done means callers can still read the response body and the returned error does not include it.