[Rust] reqwest shallow object query param

[whirm]

• Add support for flat object query parameters.
• Expand objectQueryParam.yaml to cover both required and optional variants.

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 Git BASH)
  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 is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

@frol, @farcaller, @richardwhiuk, @paladinzh, @jacob-pro, @linxGnu Ready to review!

[linxGnu]

IMHO, having unimplemented here may cause unexpected panic from user point of view. How about auto fallback to parse_deep_object:

serde_json::Value::Object(_) => {
   return parse_deep_object("", value);
}

or just don't handle it, let it fallback to _ =>

[whirm]

The user should never see that. That's a developer targeted error.
As far as I can tell, the only way a user sees this, is if a developer makes a mistake modifying the templates in a way that uses the wrong parse fn.

And I'd say that if I let it pass through, then it will generate incorrect values (I don't think converting objects to strings will be very useful) and will make figuring out that someone broke the templates more difficult.

Or I'm missing something here?

[linxGnu]

@whirm sorry for late reply

As far as I can tell, the only way a user sees this, is if a developer makes a mistake modifying the templates in a way that uses the wrong parse fn.

Yeah, that is my point of view.

I would love to see:

1. CodeGen error/failure on detection of misconfiguring specs (e.g nested object in query params)

• IMHO, it's Code Generator responsibility/feature

3. In the context of query params, guarantee that isModel always represents a flat object

• For (1), we must touch Code Generator (written in Java)
• For (2):
  • If isModel always represents a flat object, then we don't need to specify unimplemented!
    • serde_json::Value::Object(_) => { // empty, do nothing }
  • If isModel does not represents a flat object for all the cases, then we need other flag/property or back to (1)

Please tell me your opinions!

[whirm]

serde_json::Value::Object(_) => { // empty, do nothing }

I would rather have an unreachable!() there so that we ensure that any potential future mistake/behaviour change results in a very obvious panic instead of silently ignoring stuff.

@wing328 Do you know about this? v

If isModel does not represents a flat object for all the cases, then we need other flag/property or back to (1)

In any case, I don't have enough free time to dedicate to 1 so someone else would have to work on that.

[wing328]

CodeGen error/failure on detection of misconfiguring specs (e.g nested object in query params)

my suggestion is to show a warning.

we try not to throw errors when a little part of the spec is not valid or makes no sense as the user may not want to use that particular endpoint/model anyway.

[whirm]

In the meanwhile #21262 got merged, which seems to bring in a superset of what I was implementing here. :)

I'll close this PR for now and create a new one if it turns out our needs are not yet fully covered.

Cheers!