[REQ] support follow redirects in swift libraries

[Jonas1893]

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

We have an API that uses ETags to implement a simple caching mechanism for large image data. We are requesting with the ETag of the locally cached image data in the request header and a response is either

• 302 with a Location redirect header redirecting the client to the blob storage with an updated ETag in the response header
• or 304 not modified, indicating that the locally cached data in the client (as indicated by the ETag) is not outdated and can still be used.

Currently two things are preventing this to work with the generator:

1. The generated APIs for responses that define redirects will currently be generated with a Void return type. Both URLSession and Alamofire libraries currently already follow the redirect URL from the location header, however the data that is being retrieved is being discarded by always mapping to Void.
2. Successful status code range is currently hardcoded for both URLSession and Alamofire implementations to 200..< 300. both 302 and 304 are treated as failure and the image data can not be returned to the caller

Describe the solution you'd like

For solving problem 1. I propose to change the return type to Data for redirect responses and pass the returned Data. This should probably sit behind a new generator flag to stay backwards compatible.
For solving problem 2. I propose to add the configuration option for changing the successful status code range. This can also be useful for other use cases beyond the scope of follow redirects, that's I would propose to add this in a separate PR

Describe alternatives you've considered

I don't think there are many other options currently other than changing the API spec and directly returning image data instead of sending Location redirects headers. However for our project this is not possible

Additional context

[Jonas1893]

Returned bodyData from redirect is now passed through Response object that can be accessed for each API. APIs that rely on follow redirects are now properly supported