This variable is always non-null.
We likely wanted to check markerSchemaName but that's also always non-null at the moment.

…looking up the schema.

The usefulness of this special case appears to have been limited to
writing tests: Our tests contained many markers which only match a
schema due to their name.

So this patch moves the special case to the handling of TestDefinedMarkers:
When the payload is absent, we synthesize a { type: <markerName> } payload
for convenience.

Markers from Firefox never needed this special case. And the special
handling caused some trouble when markers were mistakenly matched
against a schema with a custom label that was referring to fields
which weren't present on the marker (because the marker doesn't have
a payload).
I found two cases of this in the wild, with "CPUSpeed" and "Awake"
markers:

The first CPUSpeed marker on https://share.firefox.dev/4gmLaif
has a null data field.
Before this patch, it matched a CPUSpeed schema. This gave it a
broken tableLabel ("CPUSpeed Speed = GHz").

For Awake markers (e.g. on https://share.firefox.dev/403suOD ), the
code in Firefox which emits these markers uses the typed marker API
for the IntervalStart marker, and the payload-less API for the IntervalEnd
marker:
https://searchfox.org/mozilla-central/rev/43ce3de32b3a946bceac74c3badf442af9f245c0/tools/profiler/core/platform.cpp#7496-7497
So unpaired end markers got a broken tableLabel from the Awake schema
before this patch ("Awake - CPU Id = " on https://share.firefox.dev/4fx8cSf ).

These two cases are fixed by this patch - the two markers get the
default tableLabel, which does not refer to these absent fields.

RefreshDriverTick markers from Firefox are Text markers.
Firefox (as of Jan 2025) has never emitted a 'RefreshDriverTick' schema.

Only pre-schema profiles have a 'RefreshDriverTick' schema, which they
get from the v33 upgrader.

Post-schema profiles don't display RefreshDriverTick markers in the
timeline-overview area, because Text markers aren't displayed there.

This commit makes the marker test consistent with what Firefox outputs.
Now it no longer relies on a special case in getMarkerSchemaName which
looks up schemas for Text markers based on the marker name.

To test timeline-overview filtering, a new marker is introduced, with
schema name 'VisibleInTimelineOverview'.

Just use data.type, like for other normal markers.

This mostly just affects the RefreshDriverTick marker from upgraded profiles:

 - Pre-schema profiles which get their schema from the v33 upgrader have a
   schema with name 'RefreshDriverTick' with 'timeline-overview' in the display array.
 - Post-schema profiles from Firefox do not have a 'RefreshDriverTick' schema.
   The RefreshDriverTick markers in such profiles is a regular Text marker,
   and Text markers do not show up in the 'timeline-overview' area.

This change makes it so that the 'RefreshDriverTick' schema from
upgraded pre-schema profiles becomes unused, and the markers vanish from
the timeline-overview area.
This is consistent with post-schema profiles.

This adjusts some markers and schemas to be more consistent with
what Firefox outputs:

Markers with { type: "Paint" / "Navigation" / "Layout" } aren't present
in any existing profiles, they were neither emitted by Firefox nor generated
by an upgrader.
Instead, these markers have { type: "tracing" } in their payload.

DOMEvent markers were tracing markers in the past, and have their own
schema today. The test now uses both variants.

CC markers were tracing markers in the past, and have their own schema
today. This test now uses the former.

Post-schema profiles from Firefox have schema with name 'tracing'.
This makes tracing markers visible in the 'timeline-overview' area.
This patch adds the tracing schema to the test profile.

This affects a test which was expecting that 'RandomTracingMarker' was not
visible in the timeline-overview area. The test expectation is adjusted.

Upgraded pre-schema profiles do not have a 'tracing' schema. This will
be fixed in the next commit.

…emas.

This adds an upgrader so that old profiles still get their CC markers
displayed in the memory track and non-CC tracing markers displayed in
the timeline-overview area.

Newer profiles don't need this special case because their CC markers have
a CC schema which correctly puts them in the memory track, and because
they include a 'tracing' schema which puts non-CC tracing markers into
the timeline-overview area.

…om getSchemaFromMarker.