feat: add Docker router-based testbed

[srene]

Summary

• Docker testbed mode (--docker) with a single router container simulating diverse public IPs and NAT behaviors via iptables
• Three node types: public, NATted (unreachable), port-forwarded (reachable on discv5 port)
• Virtual public IPs scattered across different /8, /16, /24 ranges so IP diversity scoring works correctly
• Per-node latency via tc netem, configurable from file or random uniform
• Replaces old NetworkDocker (per-node bridge with private 172.20.x.x IPs that bypassed IP limits)

New files

• testbed/docker/node/Dockerfile + entrypoint.sh — geth devp2p node container
• testbed/docker/router/Dockerfile + entrypoint.sh — iptables NAT rules engine
• testbed/discv5-docker-config.json — example config with NAT params
• Updated testbed/testbed/network.py with NetworkDockerRouter class
• Updated testbed/README.md with full documentation

Test plan

• Test on Linux machine (ssh sergi@london)
• Verify router iptables rules are applied correctly
• Run 100-node experiment with mixed NAT (50 public + 20 port-forwarded + 30 NATted)
• Verify IP diversity scoring works (non-private IPs)
• Verify NATted nodes can register but not serve as registrars
• Verify port-forwarded nodes are reachable on discv5 port
• Compare results with local mode baseline

Closes #17

[fjl]

does this work now?

[srene]

does this work now?

i dont think so. it needs to be completed and tested

[srene]

Closing in favor of #51, which simplifies the Docker testbed by dropping NAT entirely.

The router-based design here (single router container with iptables NAT classes for public / port-forwarded / natted) was solving a problem that turned out to be out of scope: NAT-class simulation isn't needed for the testbed's actual purpose. With NAT removed, the router has no remaining role — each container can simply have its real IP on a single bridge.

#51 keeps what mattered:

• Per-node configurable IP (docker run --ip)
• Per-node bandwidth + latency (tc htb + tc netem inside each container)
• IP layout across distinct /24s (node N → 10.100.N.1) to exercise regBucketSubnet=24

…and drops the rest:

• No router container, no dummy0, no iptables NAT chain
• No host-level iptables --flush (no sudo required)
• No virtual public IPs

Net change vs this PR: ~⅓ the testbed code. Easier to reason about, no privileged host setup beyond --cap-add=NET_ADMIN per container.

The testbed scope here drifted away from what's actually useful for protocol testing. #51 reflects the simpler scope. Will validate on a Linux host before marking #51 ready for review.