Adds option to stop background download controller reading to disk

[simonmitchell]

Added this so we can (try and) avoid Background download daemon's 40mb memory limit!

Description

Added a property to background controller init method to stop it reading downloaded file to Data immediately.

How Has This Been Tested?

Has been tested with the implementation of background downloading storm delta bundles in ThunderCloud

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[BenShutt]

Not sure this is needed as in instance property

[simonmitchell]

We need it to check on line 66 if we're going to read the file into Data :D

[BenShutt]

Oh sorry Github was hiding code an thought it was part of the init, my bad, that was a bit silly :P

[BenShutt]

Good idea to save a (possibly) unnecessary read :).

Makes sense why URLSessionDownloadTask only returns a file URL.
Then again surely URLSessionDownloadTask is more or less the same as an URLSessionDataTask just saving the Data to a file on successful response. So a URLSessionDataTask then writing that data manually in the callback is the same time overall?

Anyway here we are using URLSessionDownloadTask so that read doesn't need to be done into Data here as per your change! :) Instead for that the user is better using a URLSessionDataTask.

[simonmitchell]

So I think URLSessionDataTask would be incrementally saving to disk on download (Certainly with the app in the background) so unsure of that, but just trying to do everything we can from our side to reduce the memory footprint as there is a much discussed (But not documented) 40mb seemingly with urlsessiond which handles background downloads :D

URLSessionDownloadTask is required in this particular case because URLSessionDataTask won't execute in the background :)

[BenShutt]

Maybe a nice feature for the future would be an improved response model based on what you're doing.
For example a DataTask Result<Data, Error>
For example a DownloadTask Result<FileResponse, Error>
where

struct FileResponse {
    var fileURL: URL

    // ...

    func data() throws -> Data {
        return try Data(contentsOf: fileURL)
    }

    // ...
}

enum for Error is powerful so we could do a lot round that

[simonmitchell]

I'd love to make the network responses more swifty for sure! Using Result is my ideal approach, in a very similar way to what you have above :D I'm just wary as this will cause us millions of breaking changes across all our apps 😂