Adding a DownloadRestrictions group policy.

content/browser/download/download_item_impl.cc

Index: content/browser/download/download_item_impl.cc
diff --git a/content/browser/download/download_item_impl.cc b/content/browser/download/download_item_impl.cc
index 28a62099bb2f1dfa13d2608c71973fe7be66d07d..ebbd3a0eb4912df61e00c31b0878eb38f9b5bf44 100644
--- a/content/browser/download/download_item_impl.cc
+++ b/content/browser/download/download_item_impl.cc
@@ -632,11 +632,11 @@ std::string DownloadItemImpl::GetRemoteAddress() const {
 
 bool DownloadItemImpl::HasUserGesture() const {
   return has_user_gesture_;
-};
+}
 
 ui::PageTransition DownloadItemImpl::GetTransitionType() const {
   return transition_type_;
-};
+}
 
 const std::string& DownloadItemImpl::GetLastModifiedTime() const {
   return last_modified_time_;
@@ -826,7 +826,8 @@ WebContents* DownloadItemImpl::GetWebContents() const {
   return nullptr;
 }
 
-void DownloadItemImpl::OnContentCheckCompleted(DownloadDangerType danger_type) {
+void DownloadItemImpl::OnContentCheckCompleted(DownloadDangerType danger_type,
+                                               DownloadInterruptReason reason) {
   DCHECK_CURRENTLY_ON(BrowserThread::UI);
   DCHECK(AllDataSaved());
 
@@ -840,6 +841,8 @@ void DownloadItemImpl::OnContentCheckCompleted(DownloadDangerType danger_type) {
   DVLOG(20) << __func__ << "() danger_type=" << danger_type
             << " download=" << DebugString(true);
   SetDangerType(danger_type);
+  if (reason != DOWNLOAD_INTERRUPT_REASON_NONE)
+    InterruptAndDiscardPartialState(reason);

[asanka, 2017/06/06 03:00:36]

The only interrupt reasons that make sense here are those that result in a
ResumeMode of INVALID. Otherwise the download may resume automatically or wiggle
out of its interrupted state. The INVALID resume mode is also important because
it causes the partial state to be discarded.

Perhaps consider restricting the interrupt reason at this point to BLOCKED or
maybe just have a boolean or enum parameter indicating that the download should
be blocked.

[MAD, 2017/06/06 18:00:28]

Héhé... Interestingly, I initially had a bool and you suggested changing it to
specify the reason... :-D

I could also change the if to only interrupt the download when the value is
blocked, and keep it open for other interruptions in the future?

Though I don't mind bringing back the bool. :-)

[asanka, 2017/06/06 18:34:18]

LOL. Apologies for the runaround :). I'll defer to the current owners in that
case. The API probably looked too custom made for this use case. I'm tempted to
say we should fold the "BLOCKED" state into a danger type, but that'll make it
difficult to note *why* the download was blocked later.

[MAD, 2017/06/12 17:38:15]

OK, thanks, I'll wait to see if the OWNERs prefer to change it to a boolean, or
restrict the interrupt reasons that can cause an interruption here.

[David Trainor- moved to gerrit, 2017/06/12 19:09:04]

I'm ok leaving the interrupt reason here.  Could we just DCHECK the expected
ResumeMode() after this call?

[MAD, 2017/06/12 19:45:13]

Done.

   UpdateObservers();
 }
 
@@ -935,7 +938,7 @@ DownloadItemImpl::ResumeMode DownloadItemImpl::GetResumeMode() const {
   bool user_action_required =
       (auto_resume_count_ >= kMaxAutoResumeAttempts || IsPaused());
 
-  switch(last_reason_) {
+  switch (last_reason_) {
     case DOWNLOAD_INTERRUPT_REASON_FILE_TRANSIENT_ERROR:
     case DOWNLOAD_INTERRUPT_REASON_NETWORK_TIMEOUT:
     case DOWNLOAD_INTERRUPT_REASON_SERVER_CONTENT_LENGTH_MISMATCH: