Remove disabled DiskCacheEntryTest.UseAfterBackendDestruction

... And make comments in disk_cache.h on ~Backend somewhat reflect
the semantic drift of that API.

It turns out that Blockfile isn't structured in a way that cleanly
permits Close to run after backend destruction --- ~EntryImpl
currently wants to be destroyed on the background thread (due to
using a weak pointer from there), but access to that thread is
owned by backend.

Bug: 811276
Change-Id: Iab92fad91a33dc3d924139bc699671fd21d7a72f
Reviewed-on: https://chromium-review.googlesource.com/999794Reviewed-by: Josh Karlin <jkarlin@chromium.org>
Commit-Queue: Maks Orlovich <morlovich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549604}

net/disk_cache/disk_cache.h

@@ -122,7 +122,11 @@ class NET_EXPORT Backend {
   // operations so the callbacks are not invoked, possibly leaving the work
   // half way (for instance, dooming just a few entries). Note that pending IO
   // for a given Entry (as opposed to the Backend) will still generate a
-  // callback from within this method.
+  // callback.
+  // Warning: there is some inconsistency in details between different backends
+  // on what will succeed and what will fail.  In particular the blockfile
+  // backend will leak entries closed after backend deletion, while others
+  // handle it properly.
   virtual ~Backend() {}
 
   // Returns the type of this cache.

net/disk_cache/entry_unittest.cc

@@ -4883,15 +4883,6 @@ TEST_F(DiskCacheEntryTest, SimpleCacheChecksumpScrewUp) {
   entry->Close();
 }
 
-// TODO(morlovich): There seems to be an imperfection of leak detection, see
-// https://crbug.com/811276. Please reenable this test when the bug is fixed.
-TEST_F(DiskCacheEntryTest, DISABLED_UseAfterBackendDestruction) {
-  // InitCache uses the kNoRandom flag that check-fails on the tested scenario.
-  CreateBackend(0);
-  DisableIntegrityCheck();
-  UseAfterBackendDestruction();
-}
-
 TEST_F(DiskCacheEntryTest, SimpleUseAfterBackendDestruction) {
   SetSimpleCacheMode();
   InitCache();