[REQ] [Swift5] Cancellation of requests

Created by: mkj-is

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

Swift 5 generated code does not support cancellation of requests. This is the case for all libraries you can configure using responseAs option (PromiseKit, RxSwift, Result, Combine) and even the standard completion handler.

Combine and RXSwift

Reactive frameworks have the concept of cancellation built-in.

The Combine generator uses Future, which does not support cancellation and is primarily designed to wrap APIs based on completion handlers. Similarly, the RxSwift Observable is created in a way the task is cannot be disposed during its execution.

PromiseKit

PromiseKit does not have the concept of cancellation built-in as of version 6.x and therefore there is not a strong need to do any updates in here.

Describe the solution you'd like

If the generated API call methods would return URL session data task, the user would be able to control the lifecycle of the request.

@discardableResult
open class func addPet(
    pet: Pet,
    apiResponseQueue: DispatchQueue = OpenAPIClientAPI.apiResponseQueue,
    completion: @escaping ((_ data: Pet?, _ error: Error?) -> Void)
) -> URLSessionTask

Discardable result is added to keep backward compatibility, so no warnings are thrown when you regenerate the code.

Combine and RxSwift

We would neet to change the execute method on RequestBuilder to also return the data task, so we can properly wrap the data task in a Publisher or an Observable.

Describe alternatives you've considered

• Copy the templates and rewrite them to fulfill our use-case and to have expanded feture set. (We did and it works fine for us. I believe this is core feature of client-server communication and many of the other users could benefit from such feature.)
• Do not care about cancellation. (We want to optimize the data requirements and it makes sense to end some requests in case we no longer need to finish loading them. This is the case for most of the GET requests or more generally for all the requests which are idempotent.)

Additional context

What do you think about this approach? I'm willing to help with the implementation, I see many ways how the Swift generator could be improved and in my opinion this is the primary feature we miss in the standard generator templates.