feat: support nexus api-version header

[sudomateo]

Updated the Go SDK to set the API-Version header to the Nexus OpenAPI specification version when making API requests.

Closes SSE-61.

[lgfa29]

Probably a good time to read this from VERSION and establish that as the source of truth for SDK version? It seems like an easy thing to miss, even with the release checklist.

I thought a quick embed would do the trick, but it can't access files from parent directory. But reading the file directly should still be simple enough. I can push a commit for this if you don't have to time to work on it.

If we prefer to keep the version here as well, I would suggest at least moving it to a const in the beginning of the file so it's easier to find it.

[sudomateo]

I'm personally not a huge fan of the external VERSION and OMICRON_VERSION files. I'd prefer to have a single source of truth for these versions, ideally within the Go source code itself. However, since we use the values within the Makefile I think it's okay to keep them as external files. I'll push a commit for it.

As an aside, I'd love to have a larger conversation around our usage of Makefiles versus moving more of that into Go itself.

[sudomateo]

I updated the implementation according to your comments. Let me know what you think.

[lgfa29]

I don't personally mind the version files. My main gripe was having the version defined (and having to be updated) in two places. One advantage of having it as a plain text file is that it's easier to parse from other tools, but we could also bring it to code by reading from the file into a variable.

As for Makefiles, I don't mind them either, as long as they're kept simple, but I would be curious to see what you have in mind.

[sudomateo]

I also don't mind the version files. For me the issue comes in the form of sprawl. Like you mentioned, having plain text files makes it easy to parse the value but then when you have multiple files you get file sprawl. Then you put the version within Go code or some structured file like JSON and now you'll get tool sprawl with the Makefile needing to call out to something like jq to parse the versions.

There's no right answer here really. I'd be curious to try an all Go approach using go run and go tool but I'm sure it'll be more complicated than Makefile targets.