Bug 1543319 - P1. Free intermediate memory as early as possible during Safe Browsing update. r=gcp

Here is the flow how prefixes are handled during an V4 update:
1. Prefixes are received from Safe Browsing update, stored in ProtocolBuffer
2. Copy the prefixes from ProtocolBuffer to TableUpdate structure
3. Prefixes in TableUpdate are merged with local prefixes (stored in LookupCacheV4)
4. Merged prefixes are processes by PrefixSet to generate the in-memory prefix
   set data structure (MakePrefixSet).

In this patch, we free the prefixes stored in TableUpdate right after step3.
This reduces the peak memory used during an update (peak happens in step 4).

Differential Revision: https://phabricator.services.mozilla.com/D26860

--HG--
extra : moz-landing-system : lando

toolkit/components/url-classifier/HashStore.cpp

@@ -221,6 +221,11 @@ nsresult TableUpdateV4::NewFullHashResponse(
   return NS_OK;
 }
 
+void TableUpdateV4::Clear() {
+  mPrefixesMap.Clear();
+  mRemovalIndiceArray.Clear();
+}
+
 HashStore::HashStore(const nsACString& aTableName, const nsACString& aProvider,
                      nsIFile* aRootStoreDir)
     : mTableName(aTableName), mInUpdate(false), mFileSize(0) {

toolkit/components/url-classifier/HashStore.h

@@ -176,6 +176,9 @@ class TableUpdateV4 : public TableUpdate {
   nsresult NewFullHashResponse(const Prefix& aPrefix,
                                const CachedFullHashResponse& aResponse);
 
+  // Clear Prefixes & Removal indice.
+  void Clear();
+
  private:
   virtual int Tag() const override { return TAG; }
 

toolkit/components/url-classifier/LookupCacheV4.cpp

@@ -642,6 +642,10 @@ nsresult LookupCacheV4::ApplyUpdate(RefPtr<TableUpdateV4> aTableUpdate,
     return NS_ERROR_UC_UPDATE_WRONG_REMOVAL_INDICES;
   }
 
+  // Prefixes and removal indice from update is no longer required
+  // after merging the data with local prefixes.
+  aTableUpdate->Clear();
+
   nsAutoCString sha256;
   crypto->Finish(false, sha256);
   if (aTableUpdate->SHA256().IsEmpty()) {