[BUG][GO] Header parameter references are hardcoded on generation

Created by: sambeckingham

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• What's the version of OpenAPI Generator used?
  • 4.1.2
• Have you search for related issues/PRs?
• What's the actual output vs expected output?

Description

I'll preface by saying this might be part of the OpenAPI 3.0 spec, but insofar I have not seen anything to suggest so.

If you start with a fresh .yaml file, and generate a Go Gin Server, it creates an 'api' folder that contains a 'copy' of the spec yaml. I put apostrophes around copy because it's become apparent that it's not actually a byte-for-byte replica.

The re-ordering of the properties seems rather benign since it's a valid openAPI spec either way, but the more concerning aspect is the Header Parameter reference is "exploded" (Not to be confused with the exploding of the parameter itself) into the yaml, which defeats the purpose of using references. (In the gist linked below, refer to line 42 of the generated version and 35 of the original to see the exact lines)

openapi-generator version

4.1.2

OpenAPI declaration file content or url

Here's a gist with the original spec and the generated file found in /api

Command line used for generation

	GO_POST_PROCESS_FILE="gofmt -w -s" openapi-generator generate \
		--api-package api \
		--enable-post-process-file \
		--input-spec ${PWD}/openapi.yaml \
		--generator-name go-gin-server \
		--output ${PWD} \
		--package-name basketball \
		--remove-operation-id-prefix \
		--type-mappings=int32=int

Steps to reproduce

Run the above command on the openapi.yaml file from the gist above

Suggest a fix

I'm not sure what the purpose of creating the copy in the api directory is for; At first I assumed it was a generic way to keep record of the the last spec that was used for generation, until I checked it into version control and saw it was different.

I'm assuming this is following the conventions described in the golang-standards/project-layout project. If so that's fine, it's a popular convention after all, but why change and reformat the source spec file? Especially in a way that prevents the DRY benefits of references? I now have to maintain the original file in the root directory and ignore the one generated in /api because it's useless, as opposed to just being able to maintain the one in /api as is convention because it's butchered during generation.

As a potential fix can we not just copy the spec YAML into the /api folder without changing it?