Let the platform pick the default suspend state at launch

Related issue:
- uBlockOrigin/uBlock-issues#1004

The fix is trivial enough that I feel confident to make
it part of current RC cycle. There are many reports of
block page at launch on Chromium.

The fix is to let the platform pick it's natural suspend
state rather than force it. Once advanced settings are
read, the suspend state will for toggled only if
`suspendTabsUntilReady` is either `yes` or `no`. This
there should no longer be blocked page on Chromium at
launch when using default settings.

Related feedback:
- https://www.reddit.com/r/uBlockOrigin/comments/gac2h8/

Author: gorhill

src/js/start.js

@@ -268,15 +268,11 @@ try {
     await µb.loadHiddenSettings();
     log.info(`Hidden settings ready ${Date.now()-vAPI.T0} ms after launch`);
 
-    // By default network requests are always suspended, so we must
-    // unsuspend immediately if commanded by platform + advanced settings.
-    if (
-        vAPI.net.canSuspend() &&
-            µb.hiddenSettings.suspendTabsUntilReady === 'no' ||
-        vAPI.net.canSuspend() !== true &&
-            µb.hiddenSettings.suspendTabsUntilReady !== 'yes'
-    ) {
+    // Maybe override current network listener suspend state
+    if ( µb.hiddenSettings.suspendTabsUntilReady === 'no' ) {
         vAPI.net.unsuspend(true);
+    } else if ( µb.hiddenSettings.suspendTabsUntilReady === 'yes' ) {
+        vAPI.net.suspend();
     }
 
     if ( µb.hiddenSettings.disableWebAssembly !== true ) {

src/js/traffic.js

@@ -1035,7 +1035,7 @@ const strictBlockBypasser = {
 return {
     start: (( ) => {
         vAPI.net = new vAPI.Net();
-        vAPI.net.suspend(true);
+        vAPI.net.suspend();
 
         return function() {
             vAPI.net.setSuspendableListener(onBeforeRequest);