Validation now exposes response data or destinationURL and supports subclasses.

Previously, the Validation closure only exposed the optional request and response parameters making it difficult to customize validations in inline closures that were not custom extensions in the `Request` class. You didn’t have access to the actual response data. This was limiting in certain cases where you want to create a custom validation error that includes the error message buried in the server data. The only way you could do this previously was to write an extension on `Request`. Now you can do it in an inline closure right at the callsight.

Another limitation was that the `Validation` closure did not expose the `destinationURL` for a `DownloadRequest` incase you needed to inspect the data in some special scenario. There is now a custom `Validation` closure on `DownloadRequest` that exposes the `destinationURL` directly. This allows you to inspect the file right in an inline closure without having to extension `DownloadRequest` directly.

Tests/ValidationTests.swift

@@ -360,12 +360,9 @@ class ContentTypeValidationTestCase: BaseTestCase {
                 -> DownloadRequest
             {
                 let originalRequest = urlRequest.urlRequest
-                let adaptedRequest = originalRequest.adapt(using: adapter)
-
-                var task: URLSessionDownloadTask!
-                queue.sync { task = self.session.downloadTask(with: adaptedRequest) }
-
                 let originalTask = DownloadRequest.Downloadable.request(originalRequest)
+
+                let task = originalTask.task(session: session, adapter: adapter, queue: queue)
                 let request = MockDownloadRequest(session: session, task: task, originalTask: originalTask)
 
                 request.downloadDelegate.downloadTaskDidFinishDownloadingToURL = { session, task, URL in