cmd/trace: port to v2 traces [freeze exception]

[felixge]

Tracking issue for updating cmd/trace for the v2 overhaul (#60773) in CL 538515.

Main Viewer:

• Basic P Lanes with G slices
• Heap Metrics
• Thread Metrics
• Goroutine Metrics
• Trace Splitting
• GC Lane
• STW Events
• Proc Start/Stop Events
• Syscalls
• Flow Events
• focustask Filter
• taskid Filter
• goid Filter (Plus some refactoring work.)
• Network Lane
• GWaitingGC State
• CPU Samples
• Add totalDuration arg for blocking syscalls (nice-to-have, see comment)

Sub-Pages:

• PPROF (CL 541999)
• MMU (CL 541258)
• Goroutine Analysis (CL 541257)
• Tasks (CL 542077)
• Regions (CL 542077)

cc @mknyszek

[heschi]

cc @golang/runtime

[gopherbot]

Change https://go.dev/cl/540256 mentions this issue: internal/trace: implement MutatorUtilizationV2

[gopherbot]

Change https://go.dev/cl/540259 mentions this issue: internal/trace: implement goroutine analysis for v2 traces

[mknyszek]

@golang/release

Hey release folks, I'd like to request a freeze exception for this work. It's a little early and there's a solid chance that we'll get this all done before the freeze rolls around, but I wanted to get this on your radar ASAP.

My reasoning for the freeze exception is as follows:

This is a blocker for enabling the new execution tracer (#60773) by default, because we shouldn't ship a runtime that produces traces that users have no tooling for.

However, this codebase is far from mission-critical. If it has bugs, it's not going to break any production services. The new execution tracer on the other hand is in good shape and will easily land before the freeze.

Simultaneously, because the new execution tracer work is largely targeting developers that build tools for other developers, asking downstream users to set a GOEXPERIMENT is a fairly high hurdle to overcome, and would effectively delay building on top of the new foundation from February to August.

Note that I'm also suggesting to enable the new execution tracer by default after the freeze window. While this seems risky, I designed the new tracer's tests to run even if the GOEXPERIMENT is disabled, so we'll still get exactly the same coverage from CI until cmd/trace is fully finished. I can also easily expand this testing to running several std packages' tests under the new tracer and validating the results if that would help ease concerns about test coverage.

I propose we also set a hard cutoff on this work at the first release candidate. If we can't get it done by the time the release candidate is being built, then we'll drop it for Go 1.22.

Note that we can still land all the in-progress changes before then (to avoid carrying an inventory of unsubmitted CLs) because cmd/trace selects its behavior based on the trace version. As a result, it'll still work exactly the same for old traces; cmd/trace will only be left in a partially-working state for new traces. This further reduces the risk and provides us with an easy off-ramp.

[heschi]

Approved if needed: we don't expect to get a lot of coverage of this feature before RC1 anyway, so as long as it lands before that it should be okay. However, please try to test with large-scale Google services as early as possible.