[go] support io.Reader and []byte response types in client decode

The Go generator maps binary types to *os.File by default. Callers can
override that with --type-mappings to get io.Reader or []byte, and
setBody already handles both for request bodies. The shared decode
helper, however, only asserts *string, *os.File, and **os.File. When
Execute declares localVarReturnValue io.Reader or []byte and calls
decode(&localVarReturnValue, ...), no branch matches and the call
returns 'undefined response type'.

Add two branches:
- *io.Reader wraps the already-buffered bytes in a bytes.Reader.
- *[]byte assigns the bytes directly. This branch must stay before the
  JSON branch, since json.Unmarshal accepts *[]byte and base64-decodes
  into it, which is not what we want for raw binary responses.

Both shapes are useful for different scenarios: []byte is more honest
(the response is fully buffered in memory anyway), while io.Reader is
forward-compatible (the return type stays valid if the response path is
ever refactored to skip the eager buffering and stream the body).

bytes is already imported in every generated client.go. The same
additive patch is applied to the eleven Go client samples.

Author: dschmidt

modules/openapi-generator/src/main/resources/go/client.mustache

@@ -539,6 +539,15 @@ func (c *APIClient) decode(v interface{}, b []byte, contentType string) (err err
 		*s = string(b)
 		return nil
 	}
+	if r, ok := v.(*io.Reader); ok {
+		*r = bytes.NewReader(b)
+		return nil
+	}
+	// Must stay before the JSON branch: json.Unmarshal would base64-decode into *[]byte.
+	if p, ok := v.(*[]byte); ok {
+		*p = b
+		return nil
+	}
 	if f, ok := v.(*os.File); ok {
 		f, err = os.CreateTemp("", "HttpClientFile")
 		if err != nil {