Use runtime.onPerformanceWarning event for breakage reports

[kzar]

Use runtime.onPerformanceWarning event for breakage reports

The new runtime.onPerformanceWarning event is fired for extensions
when the browser detects a runtime performance issue. This is so that
extension developers can be notified and proactively investigate
performance issues in their extensions.

Initially, the event will be available with Firefox 124 and will fire
only for serious content-script hangs[1]. (For those hangs, the user is
also shown a warning banner[2].) In the future, the event will
hopefully be available on more browsers, will include stack traces
where possible and will fire under more conditions.

For now, let's just include a basic performanceWarning flag with
breakage reports, that indicates if the event fired for the tab in
question. In the future, we can expand this as necessary to include
details of stack traces and warning type and category.

1 - https://bugzilla.mozilla.org/show_bug.cgi?id=1861445
2 - "EXTENSION NAME" is slowing down Firefox. To speed up your browser, stop that extension. Learn more

Reviewer: @jdorweiler
CC: @GioSensation, @sammacbeth

Steps to test this PR:

For the review:

1. Check the unit tests pass.

How I tested for real:

1. Created a content-script that hangs, e.g.:

const finish = performance.now() + 10000;
console.log("Hang starting at", new Date());
while (performance.now() < finish) {
    true;
}
console.log("Hang finished at", new Date());

2. Inspected network requests for the extension background "page".
3. Sent a breakage report and ensured performanceWarning=false was sent.
4. Triggered the hanging content script and kept clicking on the page while the hang was active, until Firefox displayed the warning banner.
5. Sent a breakage report again, and ensuredperformanceWarning=true was sent.

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

[sammacbeth]

I missed this, but have a refactor suggestion to make this code easier to test and inline with the architecture we're moving towards.

[sammacbeth]

I'd prefer if this was in a separate file - I'm trying to move us away from having everything registered in events.js. Instead we could:

• Move this to a 'component', that runs this code in the constructor.
• Instantiate this component in background.js only for Firefox builds.

This has the advantage that it makes this code much easier to test. I see you had to add a load of stubs to handle importing events.js in a unit-test. Using the component architecture would remove the need for that, and you could also pass in a mock tabManager instance.