Add routing stats module

[erayd]

Adds some basic routing stats to assist with infrastructure planning and identifying problems. The idea is to have this enabled on infrastructure high sites. I also intend to add replay stats to this later, as part of the replay PR.

• Transmission of stats is disabled by default, and can be configured to an arbitrary interval (seconds).
• Received stats will be printed to the console upon receipt.
• Local stats will be printed to the console every 60 seconds.

Tracked metrics:

• Channel util %
• TX util %
• TX milliseconds
• RX milliseconds
• Total number of packets sent
• Number of relayed (rebroadcast) packets
• Number of packets originated (excl. zero-hop)
• Number of zero-hop packets originated
• Number of packets dropped from the TX queue
• Maximum number of packets waiting in the TX queue
• Total number of packets received
• Number of receive events where the incoming data couldn't be decoded to a packet
• Number of packets received originating from a direct neighbour (excl. zero-hop)
• Number of zero-hop packets received
• Number of packets received with hop_limit=0 (excl. zero-hop)

Requires meshtastic/protobufs#799

🤝 Attestations

• I have tested that my proposed changes behave as described.
• I have tested that my proposed changes do not cause any obvious regressions on the following devices:
  • Heltec (Lora32) V3
  • LilyGo T-Deck
  • LilyGo T-Beam
  • RAK WisBlock 4631
  • Seeed Studio T-1000E tracker card
  • Other (please specify below)

[GUVWAF]

Looks definitely useful. It has some overlap with LocalStats (which actually can also be requested remotely). Maybe it makes sense to include the new metrics from this module there as well? Then you don't need to enable this for nodes you can reach with a client app.

Also, probably good to enforce a minimum broadcast interval to avoid this becoming an airtime hog just like NeighborInfo was.

[erayd]

It has some overlap with LocalStats (which actually can also be requested remotely). Maybe it makes sense to include the new metrics from this module there as well? Then you don't need to enable this for nodes you can reach with a client app.

I had no idea that LocalStats was remotely requestable. That's good to know. I do think it serves a different purpose though - this one is very much intended as a live diagnostic tool, which is why most of the metrics are windowed. The stuff in LocalStats is mostly on a since-boot basis, isn't it?

Also, probably good to enforce a minimum broadcast interval to avoid this becoming an airtime hog just like NeighborInfo was.

Fair point. IMO it should be imposed after a timeout though - because this is a diagnostic tool, I want to be able to set it to e.g. a two minute window specifically in order to get a better resolution on peaks. Would having the value automatically clamped to max(1 hour, configured interval) after e.g. 4 hours of runtime be acceptable? That way small values can stll be configured while actively testing, but it ensures the device doesn't remain in that state indefinitely.

[GUVWAF]

I had no idea that LocalStats was remotely requestable.

I believe it's only available using the Python CLI with --request-telemetry local_stats.

The stuff in LocalStats is mostly on a since-boot basis, isn't it?

Correct. Indeed it's a slightly different purpose and periodic broadcasts can be valuable.

Would having the value automatically clamped to max(1 hour, configured interval) after e.g. 4 hours of runtime be acceptable?

Sounds good to me.