pkg: add chrome tracing stat events

[Alizter]

We add some more chrome tracing events to various pkg related areas. In order to do this ergonomically, we introduce some convenience wrappers for Dune_stat which appear to be quite pleasant to use.

• cat:sys_poll
  • name:make
• cat:opam_repo
  • name:load_all_versions_by_keys (this needs a better name)
• cat:solver
  • name:repo_candidate
  • name:build_problem
  • name:solve_package_list
• cat:lock_dir
  • name:write_lock_dir (these don't match the code names)
  • name:load_lock_dir
• cat:fetch
  • name:dune-fetch (needs rename)
  • name:extract
• cat:pkg_rules
  • name:setup

[Alizter]

The CI errors are from the recent portable lock directories. Might be worth noticing we are doing 4x the work in some places.

[Leonidas-from-XIV]

The concept is very useful and I agree it would be nice to have more insight to see what we're spending our time on.

I think something that is missing is an event that measures how long it takes us to set up pkg_rules. Given OPAM builds have zero and dune pkg builds have to construct rules for all packages on every startup, this could be where a lot of the time is spent on null-builds.

Is there a way to make this whole thing a bit less "boilerplate-y"? I know some noise is going to be expected but the creation of events is fairly boilerplate-y. Maybe Dune_stat could have a wrapper for the start function that can abstract away a bit of the boilerplate of declaring an event.

Likewise, maybe one could create a custom let operator, that way they wouldn't need to be wrapped to add a Dune_stats.finish? My concern is that all the trace event definitions make readability of the code that is wrapped worse: 13 events added at the cost of around 300 additional lines of code, more layers of nesting. Maybe that's just the cost of timing, but if it was easier to add it would be less of a syntactic hurdle to use it more.

[Alizter]

@Leonidas-from-XIV Regarding boiler plate, the answer is yes. I've developed some helpers to better integrate with our various usage points. I can introduce them in this PR but only for the events I am adding as changing existing events will be more noise.

[Leonidas-from-XIV]

Yes, introducing them in this PR only for the events here sounds like the best way to go about it. We can update the other ones in an additional chore:-style PR in the future, there is no rush.

[Alizter]

I've introduced some helpers and gone with the let bindings. I've opted for Dune_stat.O.(let&) and Dune_stat.Fiber.O.(let&) as not to collide with existing let operators. I think it is working quite well and should make using Dune_stat more convenient.

[Alizter]

I intend to remove this, need to think a bit more about how we are stating at its call sites.