[REQ] [Ruby] No exceptions on non-success response when calling with_http_info

Short problem description

The ruby client does not discriminate between high-level and low-level calls to the API when deciding if an exception should be raised on a non-success return code from the server.

Long problem description

When using the ruby client, any errors returned by the server (e.g. response code 400) result in an ApiError exception getting thrown. See https://github.com/OpenAPITools/openapi-generator/blob/1f7824c0830f7caf68ba8b1ed91f2fdf5096a878/modules/openapi-generator/src/main/resources/ruby-client/api_client_faraday_partial.mustache#L21-L24 and https://github.com/OpenAPITools/openapi-generator/blob/1f7824c0830f7caf68ba8b1ed91f2fdf5096a878/modules/openapi-generator/src/main/resources/ruby-client/api_client_typhoeus_partial.mustache#L21-L24 where the conditional response.success? false runs into that branch.

This happens for the high-level call to the {{operationId}} method as well as the low-level call to the {{operationId}}_with_http_info method. Intuitively, I would expect the _with_http_info method to be less opinionated in what should surface as an exception.

Desired solution

Calling the high-level {{operationId}} method results in exceptions on server errors following the current behavior.

Calling the low-level {{operationId}}_with_http_info method returns the status code, (deserialized) data, and response headers on any server response. Lower-level issues, such as connection timeouts, connection errors, cURL issues, should still throw exceptions.

Keeping the behavior of the high-level interface the same as before would aid in backwards-compatibility, as only the call sites that use the low-level method need to be adjusted. I expect many ruby clients to be able to drop custom rescuing of ApiErrors in favor of working directly with the returned data from the low-level interface.

If this is in fact the solution that the maintainers here feel is appropriate, I will provide a pull request with the necessary (breaking) changes.

Alternative solutions

Two alternative options were considered:

1. Catching the exception at select call sites where processing is required based on error codes from the server.
   While a possibility (and currently implemented workaround), it cannot make use of the other nice things that the client does, such as deserialization of the data. (See https://github.com/OpenAPITools/openapi-generator/issues/12588 with a similar problem.)
2. Using locally modified mustache templates to implement this different behavior.
   Technically possible. However, it would be nicer to have these changes upstreamed. The discussion surrounding this problem is the main motivation for opening this issue.

Additional context

This behavior was discovered upon trying to implement custom logic based on the status_code response from the _with_http_info client method, where a status 400 would need parsing of the body to choose further processing paths of the request payload before resending.

The high-level method is here: https://github.com/OpenAPITools/openapi-generator/blob/1f7824c0830f7caf68ba8b1ed91f2fdf5096a878/modules/openapi-generator/src/main/resources/ruby-client/api.mustache#L44-L47

The low-level method starts here: https://github.com/OpenAPITools/openapi-generator/blob/1f7824c0830f7caf68ba8b1ed91f2fdf5096a878/modules/openapi-generator/src/main/resources/ruby-client/api.mustache#L77

Start with modules/openapi-generator/src/main/resources/ruby-client/api_client_faraday_partial.mustache and api_client_typhoeus_partial.mustache, then compare the high-level and low-level entry points in ruby-client/api.mustache. Verify that high-level calls preserve exception behavior while _with_http_info returns status, deserialized data, and headers for server responses, without hiding transport errors.