Trace the end-to-end time spent on handling GMessages

[masih]

Add detailed time metrics to trace exactly how much time is spent on what right from sub.Next for granite topic to the end when the message is either buffered elsewhere for post processing or handed to gpbft.

Context
In passive testing at scale 50% we see "subscriber too slow" logs increase with QUALITY quorum of senders drop to ~50%. When the buffer size was doubled to 256, the log rate decreased and the quorum of senders in QUALITY phase increased to ~65%.

We need these metrics to understand what exactly is slow in processing.
We know that a fair chunk of time is spent on fetch committee ( though testes were run with power override which does significantly reduce the time spent on fetching committee )

[BigLep]

Slack context: https://filecoinproject.slack.com/archives/C0556MSR945/p1744794111019479

[BigLep]

2025-04-22 conversation: we have the coding done, but there is an operational side to collect the traces. This is probably another day to do the operational side.

Our guess is this won't affect parameters for activation.

[BigLep]

2025-05-02 conversation: deferring because it's clear that the biggest time is spent in committee and proposal fetch (sometimes upwards of 10 seconds), and we have data on those already. Optimizing those is Lotus work and that is where we should spend time rather than full end to end tracing.