Change the marker schema to accept a description and get rid of the notion of static fields

[mstange]

In a marker schema, the data array can currently hold both "dynamic" and "static" fields. Dynamic fields get their value from each marker, static fields have a single fixed value.

In the years since the marker schema has been available, the only thing we've used "static" fields for is a "description" field.

So I think we should just have an actual description field which is separate from schema.data. And we should remove generic "static" fields. This simplifies the format, and it also simplifies our code because we can iterate over the fields without having to check whether a field is a static or a dynamic field - Flow was requiring extra verbose checks in this case because the two field types don't have a shared discriminator property.

This change does make the schema a little less expressive, but nobody was making use of the extra expressivity.

Also, at some point we'll want to move to a more compact representation of markers in the profile JSON by not repeating the field keys on every marker. One way to do this would be to store marker field values in an array, where each array value maps to the field at the corresponding index. This representation makes more sense if the fields array only contains fields that actually get their value from the marker.

This PR only changes the processed format. The Gecko profile format remains unchanged. We can change it in a follow-up.

On the Gecko side, we currently have an old and a new way to declare marker schemas. The new way got rid of static fields too and just accepts a description (but still outputs the description as a static field).

[codecov]

Codecov Report

Attention: Patch coverage is 93.58974% with 5 lines in your changes missing coverage. Please review.

Project coverage is 86.03%. Comparing base (2eb2bf6) to head (85bd298).

Files with missing lines	Patch %	Lines
src/profile-logic/processed-profile-versioning.js	85.71%	3 Missing ⚠️
src/profile-logic/process-profile.js	92.00%	2 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5385   +/-   ##
=======================================
  Coverage   86.03%   86.03%           
=======================================
  Files         312      312           
  Lines       30318    30350   +32     
  Branches     8288     8291    +3     
=======================================
+ Hits        26084    26112   +28     
- Misses       3640     3644    +4     
  Partials      594      594           

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

[canova]

Looks good to me, thanks.

It makes sense to me overall, considering that we are not using for something other than the description. But do we know if that's also the case for external tools that export our data, like vernier? I hope that won't affect others.

[mstange]

I've run the batch-checker over this and the only warnings from this I found were the ones about "Marker: UserTiming". But my list of profile hashes probably doesn't include a lot of third-party generated profiles.

So now I've gone ahead and checked a few profile generators:

• Ultra: All marker schema fields have a key, example
• Vernier: No static fields either
• JFRtoFP: The only use of MarkerSchemaDataStatic is this use for a "description" field
• Lean: Doesn't appear to use markerSchema at all (sets it to an empty array)
• wasmtime: Only a single marker type with no fields