feat: benchmark logs

[richard-ramos]

No description provided.

[Copilot]

Pull Request Overview

This PR introduces "mixrunner", a comprehensive benchmarking and testing framework for the Mix protocol implementation. The framework enables performance measurement and testing of mix network operations through Docker-based deployments.

• Adds conditional benchmarking instrumentation throughout the mix protocol to track message processing and timing
• Implements a complete mixrunner example with node management, Docker containerization, and automated testing capabilities
• Provides utility functions for node information serialization and multi-address management

Reviewed Changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
mix/mix_protocol.nim	Adds conditional benchmarking code with timing measurements and metadata tracking for mix message processing
mix/mix_node.nim	Adds utility function to update mix node multi-addresses by index
mix.nim	Exports the new multi-address initialization function
examples/mixrunner/node.nim	Implements node information management with serialization/deserialization capabilities
examples/mixrunner/mixrunner.sh	Provides Docker orchestration script for running multiple mix nodes
examples/mixrunner/main.nim	Main application logic for mixrunner with libp2p integration and message handling
examples/mixrunner/cron_runner.sh	Cron-based scheduling utility for automated test execution
README.md	Updates documentation with new usage instructions and Docker build information
Dockerfile	Multi-stage Docker build configuration for the mixrunner application

Comments suppressed due to low confidence (1)

examples/mixrunner/main.nim:1

• The command contains a typo: 'sexamples' should be 'examples'.

import chronos, chronicles, results

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[AkshayaMani]

Thanks for adding the logging! :) I’ve just left a couple of minor suggestions around logging structure and clarity.
Marking it as Request Changes mainly to move the DST-related changes and files into a separate branch.

[AkshayaMani]

As discussed, we could move the DST-related changes to a separate dst-gossipsub-test-node branch for now, until we figure out if/how to split it into a separate library.
We can keep just the logging-related changes in mix_protocol.nim in the main-s2 branch for debugging.

[AkshayaMani]

Optional: If we plan to expand benchmark support or keep these logs around, it might be worth extracting the repeated logging logic in handleMixNodeConnection (e.g., startTime, endTime, procDelay, shared log fields) into a small helper.
This would complement the existing SendPacketConfig abstraction used in sendPacket and help reduce duplication across Exit, Reply, etc. paths.

[AkshayaMani]

Minor suggestion: IIRC, this assumes a fixed GossipSub message layout (message size = 100) as defined in tmp/mix-gossipsub-logging branch. Might be worth adding a short comment or defining constants just to make that assumption clearer.