[go] Correctly set default array value on query parameters

[rgroothuijsen]

When an array is specified as the default value for a query parameter, the value is incorrectly output as a serialized Java array, which leads to invalid Go client code. This adds an extra check to output default array values in the expected syntax and adds the value to the query parameters.

The existing r.{{paramName}} = &defaultValue line in the template was preserved as an existing behavior, though I'm not entirely sure what it does in this context.

Fixes #21077

@antihax @grokify @kemokemo @jirikuncar @ph4r5h4d @lwj5

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 || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  (For Windows users, please run the script in WSL)
  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*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• File the PR against the correct branch: master (upcoming 7.x.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
• If your PR solves a reported issue, reference it using GitHub's linking syntax (e.g., having "fixes #123" present in the PR description)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

[Mattias-Sehlstedt]

Might not be question that you can answer, but what is the background for wanting the generated client to submit the default value that is present in a specification?

The purpose of the default is for the server to specify a fallback that is used if the client does not submit a value. The current behavior where we send the default ourselves as a client means that we will not follow any changes in the default that the server does. So if the server change their default, and their specification, we will still send the old default until our client is regenerated. I.e., we are completely unable to use the default behavior that the server uses.

So rather than fixing so that it is send, I would argue that the default value should only be used in the generated code as documentation, and not something that is actually sent.

[wing328]

but what is the background for wanting the generated client to submit the default value that is present in a specification?

the use case we came across a while ago was that the server didn't perfectly conform to the spec

ideally the issue should be fixed in the server instead but the goal is to have a functional client before the fix happens.

i'll try to create a normalizer rule later to omit the default value in the spec so that users can choose the behavior based on their situation.

[wing328]

did a simple test locally and the result is good

thanks for the PR

[Mattias-Sehlstedt]

the use case we came across a while ago was that the server didn't perfectly conform to the spec

ideally the issue should be fixed in the server instead but the goal is to have a functional client before the fix happens.

i'll try to create a normalizer rule later to omit the default value in the spec so that users can choose the behavior based on their situation.

Thanks for the background. The suggestion sounds like a good compromise given the situation 👍