Profile format changes for flows and stack-based markers

[mstange]

Corresponding platform bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1929913

This PR implements only the format changes for the current strawman proposal in #5178. So this is just the minimum so that we can start prototyping and upload profiles that contain flow fields. No UI is actually implemented - the new field types are treated just like unique-string fields are treated today.

I'm not sure if the format proposed in #5178 is the best way to represent flows. But we can still change the format later if we determine something else works better.

---

This PR changes the type definition for marker schema field types and for the marker schema itself, to include the new field types 'flow-id' and 'terminating-flow-id'. It also has some minimal changes to treat the new field types as if they were unique-string fields.
Somewhat unrelated to flows, it also adds an optional isStackBased field to the marker schema type, which is currently unused. This is for #3141 .

Additionally, it increments the version of the two profile formats, so that profiles with the new field types won't be loaded by older front-ends.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.57%. Comparing base (e0ab0b6) to head (dbc0f75).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5186   +/-   ##
=======================================
  Coverage   88.56%   88.57%           
=======================================
  Files         308      308           
  Lines       28011    28018    +7     
  Branches     7578     7583    +5     
=======================================
+ Hits        24809    24816    +7     
  Misses       2985     2985           
  Partials      217      217           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[julienw]

Thanks,
the only concern I have is with bumping the gecko version, depending on your plan on the gecko side. If you plan to land the gecko side for these new types soon, then that's good.

[julienw]

Instant markers are already displayed on a separate line anyway.

[mstange]

Well, this is proposing that we put stack-based instant markers into the pyramid.

[julienw]

I still wonder if simply ordering markers by startTime would be good enough for getting the pyramid shapes? But I'm not opposed.

[canova]

If I understand correctly, the idea of this field is to have a different section in the marker chart (instead of grouping markers by their categories and then by their names), so marker from different categories + names can be still stacked on top of each other.

I think we had the idea of having a checkbox in the marker chart to convert all the markers into stack based markers, right? So all the makers could be nested instead of only a handful selected ones. That could be something we can explore too, but having some markers behave stack based by default can be useful for the default view.

[mstange]

If I understand correctly, the idea of this field is to have a different section in the marker chart (instead of grouping markers by their categories and then by their names), so marker from different categories + names can be still stacked on top of each other.

That's right.

I think we had the idea of having a checkbox in the marker chart to convert all the markers into stack based markers, right?

I don't think it would work very well if you have non-stack-based markers in there, like CSS animation markers, IPC messages, network markers, FirstContentfulComposite markers, GCMajor markers etc. I really do think we need to have a distinction because otherwise the pyramid shape will be messed up.

[julienw]

note we also need to implement and bump the version on the gecko side fairly at the same time. Otherwise we might run into a situation where another change will want to bump the format version (eg paul bone's changes on the memory counters) and we wouldn't have the same version on the backend and frontend...

If all we want to do for now is experimenting, it might not be necessary to bump the gecko format version until we actually land it on the gecko side. Until then Jeff and yourself will have to remember you need to have an updated frontend.

(it's fine to bump the processed format version though).

[mstange]

I'll put up a patch that bumps the Gecko version into https://bugzilla.mozilla.org/show_bug.cgi?id=1929913 . I think that's the cleanest way to approach it.

[canova]

Looks good to me too, thanks!

[canova]

If I understand correctly, the idea of this field is to have a different section in the marker chart (instead of grouping markers by their categories and then by their names), so marker from different categories + names can be still stacked on top of each other.

I think we had the idea of having a checkbox in the marker chart to convert all the markers into stack based markers, right? So all the makers could be nested instead of only a handful selected ones. That could be something we can explore too, but having some markers behave stack based by default can be useful for the default view.

[mstange]

Thanks for the reviews!