sync: Populate debug counters for directory types

sync: Populate debug counters for directory types

Modifies the directory update handlers and commit contributors to make
use of the debug info emitters.  Previously, the debug info emitters
were available but unused.  This change makes it so the counters are
updated and their observers notified at appropriate times.

Updates some tests to rely on these counters rather than the
StatusController.  Eventually, these counters will replace most existing
uses of StatusController.

The code does not currently contain any non-test observers, so these
newly updated values are currently not reported anywhere.

BUG=349301
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=270590

[rlarocque, 2014-05-07 23:43:59]

Please review.

[tim (not reviewing), 2014-05-12 17:33:53]

https://codereview.chromium.org/271613006/diff/1/sync/engine/conflict_resolver.h
File sync/engine/conflict_resolver.h (right):

https://codereview.chromium.org/271613006/diff/1/sync/engine/conflict_resolve...
sync/engine/conflict_resolver.h:57: UpdateCounters* counters);
It's unfortunate to have two status-tracking parameters doing analogus work
adding complexity at all the callsites. There's a fair bit of this happening.
What's the roadmap to removing StatusController? If you can't replace it, you
should follow the StatusController pattern and have it update UC under the hood,
OR have UC update StatusController under the hood. (alternatively we could plumb
around an adapter that knows how to update both with an interface that is the
union of the two.)

[rlarocque, 2014-05-12 18:13:18]

https://codereview.chromium.org/271613006/diff/1/sync/engine/conflict_resolver.h
File sync/engine/conflict_resolver.h (right):

https://codereview.chromium.org/271613006/diff/1/sync/engine/conflict_resolve...
sync/engine/conflict_resolver.h:57: UpdateCounters* counters);
On 2014/05/12 17:33:53, timsteele wrote:
> It's unfortunate to have two status-tracking parameters doing analogus work
> adding complexity at all the callsites. There's a fair bit of this happening.
> What's the roadmap to removing StatusController? If you can't replace it, you
> should follow the StatusController pattern and have it update UC under the
hood,
> OR have UC update StatusController under the hood. (alternatively we could
plumb
> around an adapter that knows how to update both with an interface that is the
> union of the two.)

The point of this effort is to replace the StatusController.  I can't do that
until the new counters are hooked up to about:sync, but it should happen soon.

Updating "under the hood" won't be a valid approach for much longer.  It's
currently handled by some explicit snapshot taking and sending calls made on the
sync thread during a sync cycle.  When update application and conflict
resolution is divorced from the sync cycle and moves to a different thread, the
logic to emit updates will need to move with it.

[tim (not reviewing), 2014-05-14 20:50:29]

lgtm

[rlarocque, 2014-05-14 20:54:57]

The CQ bit was checked by rlarocque@chromium.org

[commit-bot: I haz the power, 2014-05-14 20:55:34]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/rlarocque@chromium.org/271613006/1

[commit-bot: I haz the power, 2014-05-15 00:38:40]

FYI, CQ is re-trying this CL (attempt #1).
Please consider checking whether the failures are real,
and report flakes to chrome-troopers@google.com.
The failing builders are:
  win_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_rel/buil...)

[commit-bot: I haz the power, 2014-05-15 06:01:15]

Change committed as 270590