Make AttachmentServiceImpl clear backoff when reconnected to network.

Make AttachmentServiceImpl clear backoff when reconnected to network.

Upon receiving a notification that network connectivity has been
restored, ASI will clear any backoff delay for uploading attachments.

BUG=411981
Committed: https://crrev.com/f144dfbeb4a4ece195b4a9d131f4a4d725debe60
Cr-Commit-Position: refs/heads/master@{#294840}

[maniscalco, 2014-09-11 22:20:47]

Patchset #1 (id:1) has been deleted

[maniscalco, 2014-09-12 16:50:22]

maniscalco@chromium.org changed reviewers:
+ pavely@chromium.org

[maniscalco, 2014-09-12 16:50:23]

Would you please review this change?

I'm not satisfied with the test coverage for ASI.

I'd like to deliver some network change events to the ASI and see how it
responds.  Delivering the events is easy, seeing how it responds is more
difficult.  For example, upon delivering "now connected" see that it resets the
backoff on TaskQueue.

I see two not-so-great options.

1. Pass in a mock TaskQueue, however, TQ is a template, so I'd need to add a
wrapper around it with virtual methods just so I can mock it.

2. Another option would be to pass the real TQ into ASI's ctor, but before
passing to ASI, the test case would give TQ a MockTimer.  The downside here is
that TQ's ctor also needs the HandleTaskCallback so that would have to come in
as a setter instead.

I'm leaning toward #2.  WDYT?  Other options?

[maniscalco, 2014-09-12 23:12:46]

On 2014/09/12 16:50:23, maniscalco wrote:
> Would you please review this change?
> 
> I'm not satisfied with the test coverage for ASI.
> 
> I'd like to deliver some network change events to the ASI and see how it
> responds.  Delivering the events is easy, seeing how it responds is more
> difficult.  For example, upon delivering "now connected" see that it resets
the
> backoff on TaskQueue.
> 
> I see two not-so-great options.
> 
> 1. Pass in a mock TaskQueue, however, TQ is a template, so I'd need to add a
> wrapper around it with virtual methods just so I can mock it.
> 
> 2. Another option would be to pass the real TQ into ASI's ctor, but before
> passing to ASI, the test case would give TQ a MockTimer.  The downside here is
> that TQ's ctor also needs the HandleTaskCallback so that would have to come in
> as a setter instead.
> 
> I'm leaning toward #2.  WDYT?  Other options?

I went with this third option we discussed in person (set mock timer on the task
queue).  I also renamed ClearBackoff to ResetBackoff and fixed some parameter
order issue in test ASSERT_s.  PTAL!

[pavely, 2014-09-13 01:23:46]

lgtm

[maniscalco, 2014-09-15 15:44:39]

The CQ bit was checked by maniscalco@chromium.org

[commit-bot: I haz the power, 2014-09-15 15:45:28]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patchset/569463002/60001

[commit-bot: I haz the power, 2014-09-15 17:12:15]

Committed patchset #3 (id:60001) as 8378af4e8d6a02278cf84425a00fe69703a25a06

[commit-bot: I haz the power, 2014-09-15 17:15:18]

Patchset 3 (id:??) landed as
https://crrev.com/f144dfbeb4a4ece195b4a9d131f4a4d725debe60
Cr-Commit-Position: refs/heads/master@{#294840}