This PR splits up the Request class into DataRequest, DownloadRequest, UploadRequest and StreamRequest subclasses.

Motivation

There were several reasons why the Request class could greatly benefit from being split up.

Progress

The first reason is that the progress APIs were stomping on each other and were confusing the users. For example, the upload progress behavior was very ambiguous considering that the same Progress instance was used to report both upload progress and then download progress after the upload was complete.

Session Manager Duplication

The feature/adapter-and-retrier PR added the TaskConvertible enumeration to the Request class. Unfortunately, there is a large amount of duplication between the TaskConvertible implementation and the Downloadable, Uploadable and Streamable enumerations inside the SessionManager. Not only is there duplication, but the Downloadable, Uploadable and Streamable enumerations don't really belong in the SessionManager anyways. They're really the pieces required to construct a concrete Request.

By splitting up the Request into subclasses, we could move the Downloadable, Uploadable and Streamable implementations into their respective subclass and eliminate the duplication with the TaskConvertible enumeration in the Request class.

In the previous PR where the TaskConvertible enumeration was added, the Downloadable, Uploadable and Streamable enumerations

Response Serializers

Another awesome reason for splitting up the Request class is to associate response serializers with a particular request type. For example, right now you can chain a responseData closure onto a Request that is backed by a URLSessionDownloadTask or a ULRSessionStreamTask. However, if you do this, what's the behavior? It currently gets really weird in all these cases when you start to consider resume data.

Also, how does one get the destination URL of a download? Great question, right now it is WAY more difficult than it should be. By splitting up the Request, we can extend only certain subclasses to support specific response serializers that are tailored to the underlying type of task. These changes will be coming in a future PR.

Solution

So now that we have some background as to why these changes would be useful, let's dig into what had to change to make this work.

TaskConvertible

By pulling the Downloadable, Uploadable and Streamable enumerations into their respective subclasses and adding a Requestable enumeration to the DataRequest subclass, I was able to get rid of the TaskConvertible enumeration and make it a protocol. The protocol now creates a URLSessionTask from a session, adapter and queue. This allows the subclassed enumerations to construct the tasks directly without having to do this in the SessionManager. This greatly simplifies the SessionManager.retry method.

Progress

The progress APIs have been completely rebuilt from scratch. You can now monitor downloadProgress on data, download and upload requests. You can also monitor uploadProgress on an upload request. There are variants for both the Progress object and the broken out Int64 values. Each variant can also call the progress closure on a specified queue.

Here's a quick example of how you can use the new APIs.

Alamofire.upload(data, to: urlString, withMethod: .post)
    .uploadProgress { progress in
        // Called on main dispatch queue by default
        print("upload progress: \(progress.fractionCompleted)")
    }
    .uploadProgress(queue: DispatchQueue.utility) { bytesSent, totalBytesSent, totalBytesExpectedToSend in
        // Can customize the dispatch queue for background operations if needed
        print("Sent: \(bytesSent), Total Sent: \(totalBytesSent), Total Expected: \(totalBytesExpectedToSend)")
    }
    .downloadProgress { progress in
        // Called on main dispatch queue by default
        print("download progress: \(progress.fractionCompleted)")
    }
    .downloadProgress { bytesRead, totalBytesRead, totalBytesExpectedToRead in
        // Called on main dispatch queue by default
        print("Read: \(bytesRead), Total Read: \(totalBytesRead), Total Expected: \(totalBytesExpectedToRead)")
    }
    .response { response in
        debugPrint(response)
    }

Download Progress

The download progress is now being tracked in the DataTaskDelegate. This allows the data, download and upload requests to leverage it. I debated for a long time as to whether to call this progress or downloadProgress. I would rather error on the side of verbosity here I think. I ultimately decided upon downloadProgress because progress is REALLY ambiguous when it comes to an upload request.

If anyone strongly disagrees here, please voice your concerns. I'm still on the fence on this one, but right now lean towards downloadProgress and uploadProgress APIs to completely avoid ambiguity.

Upload Progress

The upload progress is all managed by the UploadTaskDelegate and is only exposed publicly through the upload request subclass. The stream request cannot chain downloadProgress or uploadProgress APIs because it no longer inherits them.

Top-Level Stream APIs

I added the top-level stream APIs to Alamofire.swift because they were missing. Just wanted to callout that this random change made its way into this PR as well.

Summary

These changes vastly improve the progress APIs and open up the ability to greatly specialize the available chained methods for each subclass. This will help avoid confusion and will allow for better customization for each request type.