core(driver): reduce required traceCategories again

[paulirish]

After #6117 allowed us to remove toplevel, I had a feeling we could remove more, like loading or benchmark trace categories.

Tried some things and... we can! It knocks another 20% off the trace size. :)

Details follow..

---

What trace events do we need?

I started by auditing all the trace events I can tell we care about. And I grabbed the category they're currently traced with in Chromium:

Trace events required by Lighthouse and their assigned categories

trace event name	categories
ActivateLayerTree	disabled-by-default-devtools.timeline.frame
Animation	blink.animations,devtools.timeline,benchmark,rail
BlinkGCMarking	(not used anymore, removing)
CompositeLayers	disabled-by-default-devtools.timeline
domContentLoadedEventEnd	blink.user_timing,rail
DrawFrame	disabled-by-default-devtools.timeline.frame
EvaluateScript	disabled-by-default-devtools.timeline
EventDispatch	devtools.timeline
FireAnimationFrame	devtools.timeline
FireIdleCallback	devtools.timeline
firstContentfulPaint	loading,rail,devtools.timeline
firstMeaningfulPaint	loading,rail,devtools.timeline
firstMeaningfulPaintCandidate	loading,rail,devtools.timeline
firstPaint	loading,rail,devtools.timeline
FunctionCall	devtools.timeline
GCEvent	(not used anymore, removing)
HitTest	blink,devtools.timeline
InvalidateLayout	disabled-by-default-devtools.timeline
Layout	devtools.timeline
loadEventEnd	blink.user_timing
MajorGC	devtools.timeline,v8
MessageLoop::RunTask	toplevel
MinorGC	devtools.timeline,v8
navigationStart	blink.user_timing
Paint	devtools.timeline,rail
PaintImage	disabled-by-default-devtools.timeline
PaintSetup	(not used anymore)
ParseAuthorStyleSheet	blink,devtools.timeline
ParseHTML	devtools.timeline
PlatformResourceSendRequest	devtools.timeline
Rasterize	(not used anymore, removing)
RasterTask	cc,disabled-by-default-devtools.timeline
RecalculateStyles	(not used anymore, removing)
RequestMainThreadFrame	disabled-by-default-devtools.timeline.frame
ResourceFinish	devtools.timeline
ResourceReceivedData	devtools.timeline
ResourceReceiveResponse	devtools.timeline
ResourceSendRequest	devtools.timeline
RunMicrotasks	v8.execute
RunTask	disabled-by-default-lighthouse
ScheduleStyleRecalculation	disabled-by-default-devtools.timeline
Screenshot	disabled-by-default-devtools.screenshot
ScrollLayer	devtools.timeline
TaskQueueManager:: ProcessTaskFromWorkQueue	(not a thing anymore)
ThreadControllerImpl::DoWork	(not a thing anymore)
ThreadControllerImpl::RunTask	toplevel (swapped, you know)
ThreadState::completeSweep	(not a thing anymore, removed)
ThreadState::performIdleLazySweep	(not a thing anymore, removed)
TimerFire	devtools.timeline
TimerInstall	devtools.timeline
TracingStartedInBrowser	disabled-by-default-devtools.timeline
TracingStartedInPage	(not emitted anymore, we synthesize it ourselves)
UpdateLayer	disabled-by-default-devtools.timeline
UpdateLayerTree	devtools.timeline
UpdateLayoutTree	blink,devtools.timeline
v8.compile	v8,devtools.timeline
v8.compileModule	v8,devtools.timeline
v8.evaluateModule	v8,devtools.timeline
V8.Execute	v8
v8.parseOnBackground	v8,devtools.timeline
XHRReadyStateChange	devtools.timeline

Then, what trace categories do we need?

If you then take all the required categories and list em out, you get:

• disabled-by-default-devtools.timeline
• disabled-by-default-devtools.screenshot
• disabled-by-default-lighthouse
• devtools.timeline
• v8.execute
• blink.user_timing
• blink,devtools.timeline
• blink.animations,devtools.timeline,benchmark,rail
• blink.user_timing,rail
• devtools.timeline,rail
• devtools.timeline,v8
• loading,rail,devtools.timeline
• v8,devtools.timeline

And turns out all the non-bold items all include either 'devtools.timeline' or 'blink.user_timing'.

This means we can stop tracing the following categories:

❌ benchmark
❌ loading
❌ latencyInfo

💣 BOOM! These account for ~20% of some of our larger traces.

---

Also disabled-by-default-devtools.timeline.frame only is used for three trace events. And we've only been collecting them to sum up our mainthread-work-breakdown numbers. However these 3 events are INSTANT events with zero duration, so.. they don't add to the numbers.

Lastly I cleaned up some of the trace events mentioned in task-groups, since I now know these events like best friends. :)

---

Addendum: What's _still_ taking up space in the trace?

First, top events, then top categories:

Basically:

• screenshots are big. This trace has 398 screenshots. That'll do it. Next is throttling the screenshot capture, i think.
• the UpdateLayer event from disabled-by-default-devtools.timeline is SUPER chatty. It's worth hunting down why devtools cares about it. perhaps there's a parent task we can use instead? ALL of them are under 0.3ms long, though 15,000 of them do add up to 376ms. But still....
  
• that's all that stands out to me, the next biggest things don't seem worth it to deal with.

ref #3596

[patrickhulce]

🔍 👨‍🔬 awesome findings! yay for 20% less trace 🎉:D

I think screenshot throttling next is a good call, IMO we could very aggressively throttle changes in a _.debounce(takeScreenshot, 500, {leading: true, trailing: true, maxWait: 1000})-style