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 53.57143% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.42%. Comparing base (c886717) to head (3b8dd07).
⚠️ Report is 1 commits behind head on main.

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

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5912      +/-   ##
==========================================
- Coverage   85.45%   85.42%   -0.03%     
==========================================
  Files         321      321              
  Lines       32139    32166      +27     
  Branches     8850     8869      +19     
==========================================
+ Hits        27463    27477      +14     
- Misses       4241     4254      +13     
  Partials      435      435              

☔ 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.