[REQ][Rust Client] New Success types lead to exessive code when using the API

Is your feature request related to a problem? Please describe.

Before #6481 has been merged this morning, my test code for using the 5.0.0 SNAPSHOT with supportAsync: true and useSingleRequestParameter: true looked something like this:

    let servers = servers_api::list_servers(&configuration, params)
        .await
        .map_err(|err| format!("API call to list_servers failed: {:?}", err))?
        .servers;

For the same behaviour, I now have to write:

    let success = servers_api::list_servers(&configuration, params)
        .await
        .map_err(|err| format!("API call to list_servers failed: {:?}", err))?
        .entity
        .ok_or("API call to list_servers failed: Response could not be parsed.".to_string())?;
    let servers = match success {
        servers_api::ListServersSuccess::Status200(response) => Ok(response.servers),
        _ => Err("API call to list_servers failed: Unexpected success status code.".to_string()),
    }?;

In my oppinion, the code has become unnecessarily complex here.

Describe the solution you’d like

I am not sure if I overlooked a way for a simpler approach, but it would be nice to only deal with one layer of error handling when using the API.

Describe alternatives you’ve considered

As this is only related to template code, I can of course change this back to the previous behaviour using a customized templates, but I would like to stick to the default templates as far as possible.

Additional context

I am now using SNAPSHOT version 5.0.0-20200613.071037-272.

Thanks for looking into this! If I can give a hand finding a solution, I would be glad to do so.

[bcourtine]

Good idea: just renamed the param to supportMultipleResponses.

[bcourtine]

Hi @HenningHolmDE ,

I am the culprit for this PR, but I agree. In the first place, I did not want to implement it because code is now more complex, but it was a feature request to handle multiple 2xx schemas (which is very rare).

After discussion with @wing328 we will propose the feature as optionnal, adding a CLI option.