GitLab

It is unsafe and generally not possible to delete the profile data of a
profile that has already been "loaded". The only safe implementation is
to mark the profile data as deleted, wait until the next time browser
process starts, ensure the profile data is not loaded, and find a time
to delete the data. This CL implements this for weblayer.

* Deletion marker are empty files in <data>/profiles_to_delete matching
  the directory names of profiles. If <data>/profiles_to_delete/foo
  exists, then <data>/profiles/foo is marked for deletion.
* If client create with a name (say "foo") matching a deleted profile,
  will try to linearly check for directory with a suffix (eg "foo.1",
  "foo.2", etc) until a directory that is not marked for deletion is
  found. "." is not part of a valid profile name, so there is no risk of
  collision.
* Now DestroyAndDeleteDataFromDisk will mark the profile for deletion,
  and only remove data with BrowsingDataRemover. It will not attempt to
  delete the profile directory.
* Nuke and Mark are run in the same SequencedTaskRunner to ensure Nuke
  is called first in a process before any mark. This ensures Nuke will
  never remove a newly marked Profile during the current process's
  lifetime.
* Nuke will delete the data and cache directories first, and only remove
  the marker if both succeeds. This ensures there is no race in reusing
  a profile path.

Add weblayer_unittests and add some unit tests for
profile_disk_operations.

Bug: 1065585
Change-Id: I4b936c9a1f31da56612095bb1088b93232c5751f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2140101
Commit-Queue: Bo <boliu@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#758430}