[Rust] Support formParams and fix list-params.

[mfarrugi]

PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh and ./bin/security/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\.
• Filed the PR against the correct branch: master, 3.4.x, 4.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.

@frol @farcaller @bjgill

---

Description of the PR

Form params were previously unsupported, and list-params would produce code that didn't compile.

Tested against a private protocol that uses

        "consumes": [
          "application/x-www-form-urlencoded"
        ],

I'll follow up with the Petstore sample updates a little later.

[wing328]

@mfarrugi thanks for the PR. I've updated the samples via 0eac812

If no further feedback on this PR, I'll merge it tomorrow.

[mfarrugi]

@wing328 thanks for taking care of the test updates.

[wing328]

@mfarrugi you're welcome. Thanks again for the PR.

[wing328]

My bad. The CI failed with the following:

warning: unused import: `super::models::*`
  --> src/apis/mod.rs:22:5
   |
22 | use super::models::*;
   |     ^^^^^^^^^^^^^^^^
   |
   = note: #[warn(unused_imports)] on by default
error[E0599]: no method named `to_string` found for type `std::vec::Vec<std::string::String>` in the current scope
   --> src/apis/pet_api.rs:115:71
    |
115 |             query.append_pair("status", &status.into_iter().map(|p| p.to_string()).collect::<Vec<String>>().join(",").to_string());
    |                                                                       ^^^^^^^^^
    |
    = note: the method `to_string` exists but the following trait bounds were not satisfied:
            `std::vec::Vec<std::string::String> : std::string::ToString`
            `[std::string::String] : std::string::ToString`
error[E0599]: no method named `to_string` found for type `std::vec::Vec<std::string::String>` in the current scope
   --> src/apis/pet_api.rs:147:67
    |
147 |             query.append_pair("tags", &tags.into_iter().map(|p| p.to_string()).collect::<Vec<String>>().join(",").to_string());
    |                                                                   ^^^^^^^^^
    |
    = note: the method `to_string` exists but the following trait bounds were not satisfied:
            `std::vec::Vec<std::string::String> : std::string::ToString`
            `[std::string::String] : std::string::ToString`
error[E0599]: no method named `to_string` found for type `models::File` in the current scope
   --> src/apis/pet_api.rs:286:28
    |
286 |             ("file", &file.to_string()),
    |                            ^^^^^^^^^
    | 
   ::: src/models/mod.rs:15:1
    |
15  | pub struct File;
    | ---------------- method `to_string` not found for this
    |
    = note: the method `to_string` exists but the following trait bounds were not satisfied:
            `models::File : std::string::ToString`
    = help: items from traits can only be used if the trait is implemented and in scope
    = note: the following trait defines an item `to_string`, perhaps you need to implement it:
            candidate #1: `std::string::ToString`
error: aborting due to 3 previous errors
For more information about this error, try `rustc --explain E0599`.
error: Could not compile `petstore_client`.

@mfarrugi can you please take a look when you've time?

[wing328]

FYI. I've disabled the test for the time being: https://github.com/OpenAPITools/openapi-generator/blob/master/pom.xml

[mfarrugi]

There are two problems:

1. The Vec<> wrapping I added appears incorrect (not sure if my protocol didn't test this, or this is more complicated)
2. File type is not handled.

I see that the hyper implementation uses unimplemented!(). I could do the same so that it will compile, but I'm not sure that it is better for a user to have a run-time error instead of a compile-time error.
Perhaps a better approach here is to make the return type of unimplemented methods !, so that they compile but are not easily callable.

I won't get to this for at least a week because of the holidays. The change should be reverted pending fixes.

[wing328]

Please enjoy the holidays. We'll revert the change for the time being.

[wing328]

@mfarrugi thanks for the contribution, which has been included in the 4.0.0-beta release: https://twitter.com/oas_generator/status/1079727020374806529.

Happy New Year and looking forward to more collaboration and contributions in 2019!