hook up background task's "startProcessing" from Java to request_coordinator

components/offline_pages/background/request_coordinator.cc

Index: components/offline_pages/background/request_coordinator.cc
diff --git a/components/offline_pages/background/request_coordinator.cc b/components/offline_pages/background/request_coordinator.cc
index 3481218caf43d8f77796d78ebf46eb9522924a1b..9d3421ef8ac0afab6688040368edb8e82d2de6ac 100644
--- a/components/offline_pages/background/request_coordinator.cc
+++ b/components/offline_pages/background/request_coordinator.cc
@@ -69,6 +69,11 @@ void RequestCoordinator::AddRequestResultCallback(
 }
 
 void RequestCoordinator::RequestPicked(const SavePageRequest& request) {
+  Scheduler::TriggerCondition conditions;
+
+  // Inform the scheduler that we have an outstanding task.

[dougarnett, 2016/06/09 21:54:27]

thought this comment wording was confusing - the scheduler is dumb about why it
is scheduled. Isn't this is really about keeping the scheduler active in case we
crash before we know if we need to be rescheduled?

// While we have a pending request, be sure the Scheduler will trigger
// again in case we crash before we know if we are done with requests. 

[Pete Williamson, 2016/06/09 22:09:48]

No, this is really about ensuring that the current request is scheduled. If this
is the first request, and no others are active, the scheduler may not have
anything at all on the list.  This will make sure it has something for the
current request.  True, it may already have something scheduled, so I can change
the wording to "Ensure that..."  The place for making sure we are scheduled is
when a new task arrives from the scheduler, not when we take something off the
request queue (I haven't added that yet).

[dougarnett, 2016/06/09 22:27:05]

Hmm, not sure I understand your response. Might be easier to sync up on in
person sometime. 

It is not clear why we need something scheduled for the request we are
processing (since the scheduler just fired a StartProcessing to do it). We are
dispatching it to offliner below and it will possibly complete and not need to
be tried again. So I think this is all about the covering for the crash scenario
and, if so, then we should identify the purpose better. If not, then I am still
missing something here.

[Pete Williamson, 2016/06/09 22:30:17]

I was thinking that we might also get here via an API call to offline a page
instead of just via the scheduler, but now that I think some more, that will go
through the scheduler too, so this always comes from the scheduler.  In that
case, I will remove this (later), and move the backup reschedule into the
scheduler module.

+  scheduler_->Schedule(conditions);
+
   // Send the request on to the offliner.
   SendRequestToOffliner(request);
 }