Load TrackerData lazily

[mallexxx]

Task/Issue URL: https://app.asana.com/0/414709148257752/1202407381883565/f GH Issue URL: https://github.com/duckduckgo/iOS/issues/1200 BSK PR: https://github.com/duckduckgo/BrowserServicesKit/pull/110 Tech Design URL: CC: @miasma13 @bwaresiak

Description: Load TrackerData lazily and asynchronously to avoid JSON Decoding during init leading to app termination at startup

Steps to test this PR:

1. Validate Content Blocking Rules load and work without issues

---

Internal references:

Software Engineering Expectations Technical Design Template When ready for review, remember to post the PR in MM

[bwaresiak]

@mallexxx If you can make this up to date, I'll find time to look at it.

[bwaresiak]

I did some tests and it seems that attribution is not handled correctly - state is inconsistent.

Scenario:

1. Enter attribution flow for some domain.
2. On vendor site see that attribution works.
3. Trigger content rule list re-application by toggling protection on and off.
4. Error - attribution is not active on the vendor site even tho it should be.

[mallexxx]

@bwaresiak I updated the Attribution logic to match the latest macOS implementation, now this scenario seems working as it should

[bwaresiak]

Overall changes to architecture look great, but there is one thing that worries me with regard to original objective:

Plan was to move loading of the data to background / non-main thread or at least decouple it from app startup flow and scene initialization. Now, since ContentBlocking has became a singleton (instead of class with static fields initialized on demand) first access to that loads all the data (config, TDS) which is in fact in app delegate didFinishLaunchingWithOptions (through PrivacyFeatures.httpsUpgrade.loadDataAsync()). So this has been moved from Scene Initialization to App Initialization flow - which is not necessarily a bad thing as we should have a bit more resources available there (I think watchdog timeout is larger there) but at the same time this may be something we may want to improve further.

Note that I don't expect this to negatively impact startup performance - after all we have been already do this exact work, just from the MainVC - so we just moved this to earlier point of time.

I'm going to retest content blocking stack Tomorrow and if everything will be fine, let's go with it, unless @miasma13 or @mallexxx has something to add to my comment. :)

[mallexxx]

I‘ve performed launch measurements and the ContentBlocking initialization at init seems totally irrelevant in launch time, StorageCache initialization has much greater effect (caused mainly by TLD init because of ineffective JSONDecoder memory usage) although not really bad

[diegoreymendez]

I just restored this branch to investigate a finding page regression.