Avoid blocking ServiceWorker initiated requests for Chrome MV3

[kzar]

We already avoid blocking ServiceWorker initiated requests in the MV2
extension, since each time we enabled the blocking of those we saw
major website breakage. In the future, we'd like to start blocking
those requests again, but we'll have to do so carefully.

Anyway, it's important that request blocking is consistent between MV2
and MV3 builds of the extension. So for now, let's also avoid blocking
ServiceWorker initiated requests for Chrome MV3 builds too.

Note: The way we do this, is to ignore requests with a tabId of
-1 (aka requests not associated with a tab). This could also
lead to other requests being ignored, but since that's
consistent with the MV2 code-path[1] it seems the right approach.

1 -

duckduckgo-privacy-extension/shared/js/background/before-request.es6.js

Line 85 in 92222c8

if (tabId === -1) { return }

Reviewer: @jdorweiler

Steps to test this PR:

1. Navigate to https://privacy-test-pages.glitch.me/privacy-protections/request-blocking and ensure ServiceWorker initiated requests aren't blocked, but other requests still are.
2. Smoke test that tracker blocking is still working generally.
3. Ensure the integration and unit tests are passing.

Automated tests:

• Unit tests
• Integration tests

Reviewer Checklist:

• Ensure the PR solves the problem
• Review every line of code
• Ensure the PR does no harm by testing the changes thoroughly
• Get help if you're uncomfortable with any of the above!
• Determine if there are any quick wins that improve the implementation

PR Author Checklist:

• Get advice or leverage existing code
• Agree on technical approach with reviewer (if the changes are nuanced)
• Ensure that there is a testing strategy (and documented non-automated tests)
• Ensure there is a documented monitoring strategy (if necessary)
• Consider systems implications