[GO][Client] Use a *os.File for the API Client when uploading and downloading

[icubbon]

Downloading and uploading files for the Go Client were broken recently but then fixed with #14046. However this fix breaks the pattern of the API returning pointers to things.

This change makes the API return *os.File and accept *os.File for uploading and downloading.

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package 
  ./bin/generate-samples.sh
  ./bin/utils/export_docs_generators.sh
  

  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  For Windows users, please run the script in Git BASH.
• File the PR against the correct branch: master (6.3.0) (minor release - breaking changes with fallbacks), 7.0.x (breaking changes without fallbacks)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

@wing328

[wing328]

cc @antihax (2017/11) @grokify (2018/07) @kemokemo (2018/09) @jirikuncar (2021/01) @ph4r5h4d (2021/04)

[darkrift]

Can we not use an io.ReadCloser instead for the upload part (at least for binary format) ?

This would abstract from being a real physical file (with a filedescriptor) while still allow to read the bytes and close the stream at the end of the process.

I'm currently facing a problem where the generated API mandates the usage of a physical file but my source stream might be coming from a different location than a physical file (fetched from s3 for instance or any other remote service).

[icubbon]

Can we not use an io.ReadCloser instead for the upload part (at least for binary format) ?

This would abstract from being a real physical file (with a filedescriptor) while still allow to read the bytes and close the stream at the end of the process.

I'm currently facing a problem where the generated API mandates the usage of a physical file but my source stream might be coming from a different location than a physical file (fetched from s3 for instance or any other remote service).

Potentially, but that would be a breaking change to the API. This is meant to fix an existing bug without breaking any current APIs.

[wing328]

Right. Let's avoid breaking changes for now before the upcoming v6.3.0 release.

One way is to add an option useAbstractionForFiles to meet requirement similar to what we've done in some of the Java generators, e.g. #14316

[wing328]

let's go with this change. i'll try to add a test later

thanks again for the PR.