Shared network and concurrency tests

[hi-liang]

Ran some tests launching 400 simple socat challenges through with following changes:

• Used shared network for single-container challenges. This ideally reduces overhead of having to allocate new ip block + related iptables rules. When a container has more than 1 instance, use existing dedidicated size=8 blocks
• Replaced mutex lock on port allocation with a semaphore, temporary reserving ports then releasing them if launch fails

Launches were initiated by a set of 8 workers sending REST requests to cmgrd simultaneously, simulating picoCTF celery workers picking up launch tasks.

Results:

Network Performance Comparison (N=400 vs. N=200)

N (Containers)	Network Type	Concurrency	Total Launch Time	Avg per Instance
400	Dedicated	1	487.407s	1218.5ms
400	Shared	1	369.876s	924.6ms
400	Dedicated	2	391.885s	979.7ms
400	Shared	2	250.898s	627.2ms
200	Dedicated	1	199.912s	995.8ms
200	Shared	1	149.583s	747.9ms
200	Dedicated	2	175.199s	875.9ms
200	Shared	2	105.832s	529.8ms

Note: there were no gains at all past concurrency of 2, possibly due to certain global locks enacted by the docker service when launching a container (I think around networking). So best we get is two launch requests possibly pipelining the overlay loading phase.

Working theory is that the network provisioning stage worsens with increased number of containers

Peak burst during picoCTF 2026 was around 800 container launch requests for lonely-island