Fix issues and feature polishing for parallel download.

Fix issues and feature polishing for parallel download.

1. Fix a bug in ParallelDownloadJob that the initial request may
generate a ReceivedSlice, and currently it will hit a DCHECK.

2. Cover the edge cases that there might be holes before the initial
request offset, now we also create requests for them, but don't chunk
more slices in this scenario. (Talked offline, we might not need this logic when some later CL checked in, but leave this here for now.)

3. When chunk into smaller slices, also consider minimum slice size
Finch configuration. So we won't have extremely small new slices.



BUG=644352
Review-Url: https://codereview.chromium.org/2783473002
Cr-Commit-Position: refs/heads/master@{#460858}
Committed: https://chromium.googlesource.com/chromium/src/+/d6d05e2a6461b0886140633e9a98a01e7c780dd5

[xingliu, 2017-03-28 00:07:22]

Description was changed from

==========
Fix issues and feature polishing for parallel download.

1. Pass is_sparse_file to DownloadFile on a parallel download.

2. Fix a bug in ParallelDownloadJob that the initial request may
generate a ReceivedSlice, and currently it will hit a DCHECK.

3. Cover the edge cases that there might be holes before the initial
request offset, now we also create requests for them, but don't chunk
more slices in this scenario.

4. When chunk into smaller slices, also consider minimum slice size
Finch configuration. So we won't have extremely small new slices.



We are also considering other ideas that make more slices half open,
however they are not implemented in this CL.

BUG=644352
==========

to

==========
Fix issues and feature polishing for parallel download.

1. Pass is_sparse_file to DownloadFile on a parallel download.

2. Fix a bug in ParallelDownloadJob that the initial request may
generate a ReceivedSlice, and currently it will hit a DCHECK.

3. Cover the edge cases that there might be holes before the initial
request offset, now we also create requests for them, but don't chunk
more slices in this scenario. (Talked offline, we might not need this logic when
some later CL checked in, but leave this here for now.)

4. When chunk into smaller slices, also consider minimum slice size
Finch configuration. So we won't have extremely small new slices.



BUG=644352
==========

[xingliu, 2017-03-28 00:07:22]

xingliu@chromium.org changed reviewers:
+ dtrainor@chromium.org, qinmin@chromium.org

[xingliu, 2017-03-28 00:07:28]

The CQ bit was checked by xingliu@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-28 00:08:11]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-28 00:20:16]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-28 00:20:17]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[David Trainor- moved to gerrit, 2017-03-29 00:27:43]

lgtm

[xingliu, 2017-03-30 18:47:55]

The CQ bit was checked by xingliu@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-30 18:48:47]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[xingliu, 2017-03-30 19:00:31]

The CQ bit was unchecked by xingliu@chromium.org

[xingliu, 2017-03-30 19:00:38]

The CQ bit was checked by xingliu@chromium.org

[xingliu, 2017-03-30 19:00:39]

The patchset sent to the CQ was uploaded after l-g-t-m from
dtrainor@chromium.org
Link to the patchset: https://codereview.chromium.org/2783473002/#ps40001
(title: "Rebase.")

[xingliu, 2017-03-30 19:01:08]

Description was changed from

==========
Fix issues and feature polishing for parallel download.

1. Pass is_sparse_file to DownloadFile on a parallel download.

2. Fix a bug in ParallelDownloadJob that the initial request may
generate a ReceivedSlice, and currently it will hit a DCHECK.

3. Cover the edge cases that there might be holes before the initial
request offset, now we also create requests for them, but don't chunk
more slices in this scenario. (Talked offline, we might not need this logic when
some later CL checked in, but leave this here for now.)

4. When chunk into smaller slices, also consider minimum slice size
Finch configuration. So we won't have extremely small new slices.



BUG=644352
==========

to

==========
Fix issues and feature polishing for parallel download.

1. Fix a bug in ParallelDownloadJob that the initial request may
generate a ReceivedSlice, and currently it will hit a DCHECK.

2. Cover the edge cases that there might be holes before the initial
request offset, now we also create requests for them, but don't chunk
more slices in this scenario. (Talked offline, we might not need this logic when
some later CL checked in, but leave this here for now.)

3. When chunk into smaller slices, also consider minimum slice size
Finch configuration. So we won't have extremely small new slices.



BUG=644352
==========

[commit-bot: I haz the power, 2017-03-30 19:03:19]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-30 19:56:05]

CQ is committing da patch.

Bot data: {"patchset_id": 40001, "attempt_start_ts": 1490900438573600,
"parent_rev": "9492ea7b7a2145a72e99178a81db98f0ac16b857", "commit_rev":
"d6d05e2a6461b0886140633e9a98a01e7c780dd5"}

[commit-bot: I haz the power, 2017-03-30 19:57:18]

Description was changed from

==========
Fix issues and feature polishing for parallel download.

1. Fix a bug in ParallelDownloadJob that the initial request may
generate a ReceivedSlice, and currently it will hit a DCHECK.

2. Cover the edge cases that there might be holes before the initial
request offset, now we also create requests for them, but don't chunk
more slices in this scenario. (Talked offline, we might not need this logic when
some later CL checked in, but leave this here for now.)

3. When chunk into smaller slices, also consider minimum slice size
Finch configuration. So we won't have extremely small new slices.



BUG=644352
==========

to

==========
Fix issues and feature polishing for parallel download.

1. Fix a bug in ParallelDownloadJob that the initial request may
generate a ReceivedSlice, and currently it will hit a DCHECK.

2. Cover the edge cases that there might be holes before the initial
request offset, now we also create requests for them, but don't chunk
more slices in this scenario. (Talked offline, we might not need this logic when
some later CL checked in, but leave this here for now.)

3. When chunk into smaller slices, also consider minimum slice size
Finch configuration. So we won't have extremely small new slices.



BUG=644352

Review-Url: https://codereview.chromium.org/2783473002
Cr-Commit-Position: refs/heads/master@{#460858}
Committed:
https://chromium.googlesource.com/chromium/src/+/d6d05e2a6461b0886140633e9a98...
==========

[commit-bot: I haz the power, 2017-03-30 19:57:19]

Committed patchset #3 (id:40001) as
https://chromium.googlesource.com/chromium/src/+/d6d05e2a6461b0886140633e9a98...

[qinmin, 2017-03-31 17:56:09]

https://codereview.chromium.org/2783473002/diff/40001/content/browser/downloa...
File content/browser/download/download_create_info.h (right):

https://codereview.chromium.org/2783473002/diff/40001/content/browser/downloa...
content/browser/download/download_create_info.h:74: int64_t length;
the initial request is always half open, right? why we need this?

[xingliu, 2017-03-31 21:46:11]

Sorry that landed this CL already, address the comment in another CL.

https://codereview.chromium.org/2783473002/diff/40001/content/browser/downloa...
File content/browser/download/download_create_info.h (right):

https://codereview.chromium.org/2783473002/diff/40001/content/browser/downloa...
content/browser/download/download_create_info.h:74: int64_t length;
On 2017/03/31 17:56:09, qinmin wrote:
> the initial request is always half open, right? why we need this?

Done, addressed in
https://codereview.chromium.org/2789623005/

Also removed the logic to send requests for slices before initial request. Just
use a DCHECK now.