[PowerShell] (multipart/form-data request) and proxy behaviour

[condorcorde]

This PR includes the following changes to Invoke-ApiClient in api_client.mustache:

1. Refactoring of existing functionality, mainly by using parameter splatting to simplify the call to Invoke-WebRequest (lines 122+).
2. Replacing (broken) support of multipart/form-data requests reported in issue #17740. This is done by calling Invoke-RestMethod: the -Form parameter is taken directly from the function $FormParameters variable without need of reprocessing. The simplicity of the replacement was preferred to a direct fix of the existing code, although the PowerShell 5 version of Invoke-RestMethod does not support the return of response headers and status ($null values are returned instead).
3. During the tests, I observed that the proxy handling triggered two different source of errors:
   On PowerShell 5:

PS C:\> $proxy = [System.Net.WebRequest]::GetSystemWebProxy()
PS C:\> $proxy.Credentials = [System.Net.CredentialCache]::DefaultCredentials
PS C:\> $effectiveProxy = $proxy.GetProxy($Uri)
PS C:\> $effectiveProxy.AbsoluteUri
https://petstore.swagger.io/v2
PS C:\> Invoke-WebRequest -Uri ($Uri + '/pet/38369') -Method GET -Proxy $effectiveProxy
Invoke-WebRequest : The ServicePointManager does not support proxies with the https scheme.

On PowerShell 7 (MacOS):

PS /> $Uri = 'https://petstore.swagger.io/v2'
PS /> $proxy = [System.Net.WebRequest]::GetSystemWebProxy()
PS /> $proxy.Credentials = [System.Net.CredentialCache]::DefaultCredentials
PS /> $effectiveProxy = $proxy.GetProxy($Uri)
PS /> Invoke-WebRequest -Uri ($Uri + '/pet/38369') -Method GET -Proxy $effectiveProxy
Invoke-WebRequest:
{
  "code": 1,
  "type": "error",
  "message": "Pet not found"
}
PS /> Invoke-WebRequest -Uri ($Uri + '/pet/38369') -Method GET -Proxy $effectiveProxy -ProxyUseDefaultCredentials
Invoke-WebRequest: The cmdlet cannot run because the following parameter is missing: Proxy. Provide a valid proxy URI for the Proxy parameter when using the ProxyCredential or ProxyUseDefaultCredentials parameters, then retry.

In the first case the call to GetProxy() may return the same URI as the target URI, but this generates an error when the protocol of the target URI is HTTPS.

In the second case, the call to GetProxy() returns $null instead, but this is incompatible with the presence of the parameter -ProxyUseDefaultCredentials.

Since both cases are equivalent to a direct request without proxy, the logic was modified to ignore them (lines 133-138).

---

• Tests of the refactored functionality and proxy changes were run on PowerShell 5 (Windows) and PowerShell 7 (Windows and MacOS).
• Tests of the multipart functionality were run on a Connectwise PSA client generated for PowerShell 7, where the issue was originally detected. No tests were run on PowerShell 5 since the number of exported functions of this library exceeds 4096. A simpler test environment would be welcome.

---

Additional issues:

1. An error is generated by Invoke-ApiClient if the parameter SkipCertificateCheck is specified in PowerShell 5. This case should be handled in configuration.mustache.
2. The BaseUrl configured for Petstore is http://petstore.swagger.io:80/v2. This generates extra errors because a redirect to HTTPS is performed, but the method of the new request is switched to GET. What is the rational for the choice to specify HTTP instead?

---

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 
  ./bin/generate-samples.sh ./bin/configs/*.yaml
  ./bin/utils/export_docs_generators.sh
  

  (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.1.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.
  @wing328

To close #17740

[wing328]

in modules/openapi-generator/src/main/resources/powershell/api_client.mustache, please replace tabs with spaces

[wing328]

appveyor (ps tests) passed via https://ci.appveyor.com/project/WilliamCheng/openapi-generator/builds/49563164

[wing328]

thanks for the PR. let's give it a try