refactor(javascript): simplify transporter.request

[Haroenv]

🧭 What and Why

Simplify transporter.request by turning it from three arguments to only two.

I can't see any significant difference between the first (request) and second (methodOptions) argument of request, so this PR changes that to both be in the first argument. requestOptions is still separate.

Other API clients don't seem to distinguish that clearly in the arguments to sendRequest, as they use mostly positional arguments

PHP:

api-clients-automation/templates/php/api.mustache

Line 263 in bf42712

return $this->sendRequest('{{httpMethod}}', $resourcePath, $headers, $queryParameters, $httpBody, $requestOptions, {{#vendorExtensions.x-use-read-transporter}}true{{/vendorExtensions.x-use-read-transporter}});

Java:

api-clients-automation/templates/java/libraries/okhttp-gson/api.mustache

Line 196 in bf42712

Call call = this.buildCall(requestPath, "{{httpMethod}}", queryParameters, bodyObj, headers, requestOptions, {{#vendorExtensions.x-use-read-transporter}}true{{/vendorExtensions.x-use-read-transporter}}{{^vendorExtensions.x-use-read-transporter}}false{{/vendorExtensions.x-use-read-transporter}});

Changes included:

• transporter.request(request, methodOptions, requestOptions) -> transporter.request(request, requestOptions)

🧪 Test

This is a breaking change if you'd be using a custom request using the requester, but I guess that doesn't count yet.

If there's a historic reason for why there are three arguments and not two, feel free to research that too

[netlify]

✅ Deploy Preview for api-clients-automation canceled.

Name	Link
🔨 Latest commit	3cf28c2
🔍 Latest deploy log	https://app.netlify.com/sites/api-clients-automation/deploys/629633cd29aa5b0008a91130

[algolia-bot]

✗ The generated branch has been deleted.

If the PR has been merged, you can check the generated code on the main branch.
You can still access the code generated on main via this commit.

[millotp]

Thank you ! It makes sense to only have 2 parameters, the original reason come from the first time we generated the client, it was built that way in openapi generator and it stayed for no good reason

[millotp]

the headers are in both the EndRequest and the Request now, but the request is not used by the http requester, only the echoRequester so it's okay but we must not get confused in the createEchoRequester, where we want the final headers and not the one from request.