Support ternaries in marker labels

[carverdamien]

This issue relates to https://bugzilla.mozilla.org/show_bug.cgi?id=2014999

parseLabel() only supports accessing fields in the marker, if we could process the fields with operators such as the ternary, we would be able to remove fields from the recorded data that can be deduced from other fields.

For example, the TimerMarker uses a prefix string field to display a ❌ when the timer is canceled. A better solution would be to use a ternary in the label string, like this

schema.SetChartLabel("{marker.data.canceled ? \"❌\" : \"\"} {marker.data.delay}");

┆Issue is synchronized with this Jira Task

[fatadel]

@canova @carverdamien What fields do we want to support for the ternary conditions? Only payload (ie, marker.data.*) or other fields (eg, marker.start) too? I think having payload only should be sufficient. At least for now. Wdyt?

Also, do we want to check for value truthiness only like in the example or do we want to support any arbitrary conditions (eg marker.start > N)?

[carverdamien]

I haven't looked at all the current markers yet so I don't know for sure which operators would/could be needed.
If we make a first change with marker.data.* and ? it's already a good start. We can add more fields and operators later if we need them.
If we add more operators, it will increase the complexity (operator can be chained).
This first change is also an opportunity to measure the cost of adding operator.

[canova]

Yeah, I would say that let's start with marker.data only to start small and with a truthy check. Then we can ask for our users to give some feedback to see if they need more. I'm a bit afraid that this could make our string parsing more costly and more complex.

Also we discussed having a more complete language for these things similar to marker search, and like padenot mentioned before (also a bit inside). But it's okay to start with this for now.

[fatadel]

Great, thanks for your inputs! @canova @carverdamien

One more question, for the true/false branches, what values should we allow? (ie A and B in marker.data.* ? A : B) The options I see are as follows:

1. Double-quoted string literals, ie "Hello World";
2. Single-quoted string literals, ie 'Hello World';
3. Escaped double-quoted string literals, ie \"Hello World\";
4. Escaped single-quoted string literals, ie \'Hello World\'.
5. Smth else?

[carverdamien]

This schema.SetChartLabel("{marker.data.canceled ? \"❌\" : \"\"} {marker.data.delay}"); is C++ code. If you print the schema, you would see {marker.data.canceled ? "❌" : ""} {marker.data.delay} => So A is "❌" and B is "".
In a first version A and B can be just strings, afterwards they could be operands maker.data.* or expressions.

[canova]

Agree, and I don't really have a preference on the quote type. But let's keep supporting a single string quote type for now instead of supporting multiple ones.