[omnibox] Fix match deletion for ZeroSuggest cached REMOTE_NO_URL

I broke match deletion in the presence of caching REMOTE_NO_URL here:
https://chromium-review.googlesource.com/c/chromium/src/+/2430227/9/components/omnibox/browser/zero_suggest_provider.cc

This CL fixes it by aggressively clearing the cache any time a
ZeroSuggest match is deleted, regardless of the request type.

I think this CL will fix the bug and it's harmless to "overaggressively"
clear the cache. Match deletions are rare, and it's just a cache.

Bug: 1136609
Change-Id: Ia8c39975bc68e0c33dccf9c08c630935e29abb2d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2462342Reviewed-by: Moe Ahmadi <mahmadi@chromium.org>
Commit-Queue: Tommy Li <tommycli@chromium.org>
Cr-Commit-Position: refs/heads/master@{#815391}

components/omnibox/browser/zero_suggest_provider.cc

@@ -242,12 +242,18 @@ void ZeroSuggestProvider::Stop(bool clear_cached_results,
 }
 
 void ZeroSuggestProvider::DeleteMatch(const AutocompleteMatch& match) {
-  if (result_type_running_ == REMOTE_NO_URL) {
   // Remove the deleted match from the cache, so it is not shown to the user
   // again. Since we cannot remove just one result, blow away the cache.
+  //
+  // Although the cache is currently only used for REMOTE_NO_URL, we have no
+  // easy way of checking the request type after-the-fact. It's safe though, to
+  // always clear the cache even if we are on a different request type.
+  //
+  // TODO(tommycli): It seems quite odd that the cache is saved to a pref, as
+  // if we would want to persist it across restarts. That seems to be directly
+  // contradictory to the fact that ZeroSuggest results can change rapidly.
   client()->GetPrefs()->SetString(omnibox::kZeroSuggestCachedResults,
                                   std::string());
-  }
   BaseSearchProvider::DeleteMatch(match);
 }