GitLab

After applying a default delay to PendingWallpaper, some tests
failed (crbug.com/779504) or have memory leak [1].

These tests indirectly called SetUserWallpaper, but they do not
care/know about this, so they do not actively wait until wallpaper
loading is done, but start the destruction directly.

This used to be okay when SetUserWallpaper had zero delay.

But when it has the default delay, the timer is still running when
the destruction starts, and the timer holds a reference to the shared
pointer of PendingWallpaper, which results in memory leak.

What's worse, if the WallpaperManager already destructs itself,
PendingWallpaper::ProcessRequest does not know it, and it crashes.

After changing the shared pointer to a weak pointer, WallpaperManager
will be able to completely manage the lifetime of PendingWallpaper.

[1] https://luci-milo.appspot.com/buildbot/chromium.memory/Linux%20Chromium%20OS%20ASan%20LSan%20Tests%20(1)/24405

Below are the description of the original CL:

1) All the PendingWallpaper requests are now subject to a delay
calculated from average loading time. However, in most cases the delay
is still zero, and this change only affects corner cases that multiple
requests coming together, which may result in wallpaper being stuck.

2) Add the account_id update in PendingWallpaper. Did not modify
the functionality of PendingWallpaper, except for some renaming.

TBR=oshima@chromium.org

Bug: 779504, 778451
Change-Id: Iae943f88bbe046849c3afab75f35a253934fe75b
Reviewed-on: https://chromium-review.googlesource.com/745022Reviewed-by: Wenzhao (Colin) Zang <wzang@chromium.org>
Reviewed-by: Alexander Alekseev <alemate@chromium.org>
Commit-Queue: Wenzhao (Colin) Zang <wzang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#512883}