Add Pause and Resume Support

[ishanjain28]

This feature has to be added in the CLI application.

If an error occurs or user chooses to cancel the active download, It'll create a file with some extension(You can choose any extension you like provided it's short and isn't used by some other huge program) which will have information about,

1. Number of parts that were active at the time.
2. URL
3. The range of bytes that each worker was originally assigned.
4. The range of bytes that have been downloaded.
5. The range of bytes that have to be downloaded when program restarts.

When the program is started again, It'll see if there is a file named <file name>.<whatever extension you chose. If such a file exists, It'll read that file and start downloading the bytes which have not been downloaded yet. And if there is no such file, It should take the given settings as input and start working normally like it does now.

You can use go-bindata to store current state of download or just use a plain JSON.

[josledp]

I'll get this one if you don't mind

[josledp]

I would like to refactor a bit the code (add a pluto struct to the package, change actual functions for receiver functions, clean up the package main by moving logic to pluto package). Is it ok?

[ishanjain28]

@josledp Yes, Sure you can work on it and it's okay to refactor it if you want. :)

[josledp]

a couple of design doubts. Will it be wise to update an state file continuously? (instead just when the context is cancelled). And, do we recover automagically the state file, or would it better to add a flag to explicitly request for it? (I would prefer adding a flag and make it explicit, as wget does, but the former is also ok)

[ishanjain28]

Updating the state of a file where the state is stored continuously may not be a good idea because of high CPU Use. Update it when the context is cancelled. And explicitly asking user if they want to resume the existing download is better.

I added few commits to main branch, There were few bugs, That I fixed.

It now runs os.Exit when there are more than 1 urls in queue because cancelling the context when there are multiple urls was causing the first download to cancel but it would continue to download remaining urls and then it won't quit regardless of sending SIGINT or SIGTERM.