Add CounterDisplayConfig to counters in the processed profile format

[fatadel]

Make counters self-describing in terms of rendering by adding display field of CounterDisplayConfig type. The value is derived from a counter's category and name fields. This data is sufficient to understand how a counter should be rendered allowing us to remove hardcoded logic for each counter.

This is the first PR for issue #5752.

[codecov]

Codecov Report

❌ Patch coverage is 57.50000% with 17 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.32%. Comparing base (4308a73) to head (3641a8e).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
src/profile-logic/processed-profile-versioning.ts	40.90%	13 Missing ⚠️
src/profile-logic/process-profile.ts	60.00%	4 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #5912 +/- ##
==========================================
- Coverage 85.37% 85.32% -0.05% 
==========================================
Files 322 322 Lines 32069 32092 +23 Branches 8814 8738 -76 ==========================================
+ Hits 27378 27384 +6 - Misses 4260 4277 +17 
Partials 431 431 

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[fatadel]

This change should NOT introduce any visually-perceivable diffs, however, please let me know if you want me to provide profiles (and under what settings if so).

[canova]

Thanks a lot for working on this Adel! It's going to be a great improvement to have generic counters in the frontend!

I'm adding some preliminary review comments that I wrote while doing a first pass. But I didn't check the existing counter track visualization code yet, I remember that they had some subtle differences in the way we visualize while discussing it with @fqueze. So I'll do another pass by checking the existing counters.

There are a few things/questions I mentioned below that are high level. For example: it would be good to make the gecko profile format to have the same display object and not only "hints".

---

Another thing I want to mention is the gecko profile format upgrader that we are adding right now. It might be easier to land the processed profile format versioning at first, and then once we have a backend patch, land the gecko profile versioning in a later PR as a follow-up. This is because if we land the gecko profile format bump now, and then we work on some other feature that we might want to land before this in the backend, we will be blocked until we have an implementation for that gecko format. So usually it's better to land them close to each other. Since we have a few PTO lined up for multiple people, I guess it's going to take a bit longer to implement the Firefox side.

To be able to do that, we can move the gecko profile upgrader to the process-profile phase. And once we bump the format, we can move that process profile phase into the gecko profile upgrader (which hopefully will be straightforward to do as a follow-up).

[fqueze]

useDecimation: whether to apply min-max decimation for dense data

Is this needed? Do you have an example of a case where not using min-max decimation is better? I thought min-max decimation was just an implementation detail of how we are drawing the charts quickly, without causing any visible change.

[fqueze]

It's going to be a great improvement to have generic counters in the frontend!

+1 It's very exciting that it'll become easy to add a new counter in a profile and see the result within minutes instead of spending hours to hack the front-end to show it!

I would recommend also looking at marker tracks (declared in marker schemas), as I think eventually we'll want to merge the marker chart implementations with the counter chart implementation. If anything in the format can be made closer, that might simplify future steps.

[fatadel]

Thanks for your valuable comments, @canova and @fqueze! I hope I've correctly addressed all of them. Please, have another look.

[fatadel]

We've decided with @canova that I will first provide another (an MVP) PR that involves leveraging this new display property to render the counters. We want to make sure that it contains enough information for the renderer before we merge this PR.

[canova]

Looks good now. I found one more thing that could benefit from being inside the upgrader. Let me know what you think!

[fatadel]

Looks good now. I found one more thing that could benefit from being inside the upgrader. Let me know what you think!

I think it makes sense to include it in this PR. I don't want to have another upgrader for such a "mechanical" change.
So, I'll migrate counter.color into display.color in the upgrader (falling back to the current defaults when it's undefined) and remove the standalone color field from the types.

This also means the track components will start reading from display.color which we wanted to keep for the second PR only, but I think it's negligible here.

[fatadel]

I've migrated the color field. Could have a look just at the last commit, pls? @canova
I will squash it once you approve.

[canova]

Looks great! Let's land it!

[fatadel]

I've migrated the color field. Could have a look just at the last commit, pls? @canova I will squash it once you approve.

Actually, it makes sense to keep that as a second commit. So, I've kept it here for history and squashed everything into main.