Clear network state only when REMOVE_CACHE is set, not unconditionally

Clear network state only when REMOVE_CACHE is set, not unconditionally

Previously, network state like HSTS data was cleared whenever
BrowsingDataRemover::Remove() was called. Some archaeology
(https://codereview.chromium.org/7717023/) reveals that the original
intention was to clear this state when REMOVE_CACHE was set, but due to
a curly brace mishap, we've been clearing it over-aggressively for
years.

When I changed this behavior to remove network state only when
REMOVE_CACHE is set, it revealed that a number of tests are relying on
state being asynchronously cleared. This is no longer the case, as for
example when only REMOVE_DOWNLOADS is set. This CL fixes that by calling
NotifyIfDone() at the end of RemoveImpl(), to catch cases where no state
is being wiped asynchronously. This is a little weird since download
removal does appear to be async -- but it matches the documentation of
BrowsingDataRemover::Observer, which says that the observer fires when
"keywords have been deleted, cache cleared and all other tasks
scheduled".

BUG=603682
Review-Url: https://codereview.chromium.org/1941073002
Cr-Commit-Position: refs/heads/master@{#391248}
(cherry picked from commit c686e3083ac8b46b2b8ce6c036554bf05a7ed9ec)

Committed: https://chromium.googlesource.com/chromium/src/+/6ea2ef944984fc750bd1677955bb099a5d5ffeea

[estark, 2016-05-10 05:50:23]

Description was changed from

==========
Clear network state only when REMOVE_CACHE is set, not unconditionally

Previously, network state like HSTS data was cleared whenever
BrowsingDataRemover::Remove() was called. Some archaeology
(https://codereview.chromium.org/7717023/) reveals that the original
intention was to clear this state when REMOVE_CACHE was set, but due to
a curly brace mishap, we've been clearing it over-aggressively for
years.

When I changed this behavior to remove network state only when
REMOVE_CACHE is set, it revealed that a number of tests are relying on
state being asynchronously cleared. This is no longer the case, as for
example when only REMOVE_DOWNLOADS is set. This CL fixes that by calling
NotifyIfDone() at the end of RemoveImpl(), to catch cases where no state
is being wiped asynchronously. This is a little weird since download
removal does appear to be async -- but it matches the documentation of
BrowsingDataRemover::Observer, which says that the observer fires when
"keywords have been deleted, cache cleared and all other tasks
scheduled".

BUG=603682

Review-Url: https://codereview.chromium.org/1941073002
Cr-Commit-Position: refs/heads/master@{#391248}
(cherry picked from commit c686e3083ac8b46b2b8ce6c036554bf05a7ed9ec)
==========

to

==========
Clear network state only when REMOVE_CACHE is set, not unconditionally

Previously, network state like HSTS data was cleared whenever
BrowsingDataRemover::Remove() was called. Some archaeology
(https://codereview.chromium.org/7717023/) reveals that the original
intention was to clear this state when REMOVE_CACHE was set, but due to
a curly brace mishap, we've been clearing it over-aggressively for
years.

When I changed this behavior to remove network state only when
REMOVE_CACHE is set, it revealed that a number of tests are relying on
state being asynchronously cleared. This is no longer the case, as for
example when only REMOVE_DOWNLOADS is set. This CL fixes that by calling
NotifyIfDone() at the end of RemoveImpl(), to catch cases where no state
is being wiped asynchronously. This is a little weird since download
removal does appear to be async -- but it matches the documentation of
BrowsingDataRemover::Observer, which says that the observer fires when
"keywords have been deleted, cache cleared and all other tasks
scheduled".

BUG=603682

Review-Url: https://codereview.chromium.org/1941073002
Cr-Commit-Position: refs/heads/master@{#391248}
(cherry picked from commit c686e3083ac8b46b2b8ce6c036554bf05a7ed9ec)

Committed:
https://chromium.googlesource.com/chromium/src/+/6ea2ef944984fc750bd1677955bb...
==========

[estark, 2016-05-10 05:50:25]

Committed patchset #1 (id:1) manually as
6ea2ef944984fc750bd1677955bb099a5d5ffeea.