Configured download_speed bandwidth limit is silently not enforced

[mkzung]

When limit_bandwidth is enabled and a download_speed is configured, the download
(ingress) limit is never actually applied to the execution-client container. Only the
egress (upload) direction is shaped, so a benchmark that is meant to run under a
constrained download bandwidth actually runs with an unconstrained download path, and
nothing warns the user.

Where

src/expb/payloads/utils/networking.py, apply_tc_limits() (called from
executor.py when self.config.limit_bandwidth is set). The code already carries a note:

# FIXME: current implementation only limits egress speed (uploading)

The download_speed value is passed to an HTB class, but that class sits on the veth's
egress root qdisc. tc on the root qdisc only shapes traffic leaving the interface
(the container's upload). Shaping inbound traffic (the container's download) requires
redirecting ingress to an IFB (Intermediate Functional Block) device and applying the
rate there, or using an ingress policer. As written, download_speed has no effect.

Impact

For a benchmarking tool this is a correctness issue rather than cosmetics: any run
configured with a download_speed limit is not actually download-constrained, so
comparisons that rely on that constraint can be silently invalid.

Suggested direction

Two options:

1. Implement ingress shaping via IFB: modprobe ifb, create an ifb device, redirect
   the veth's ingress to it (tc filter ... action mirred egress redirect dev ifbN), and
   apply the HTB download_speed rate on the IFB egress. Tear it down on cleanup.
2. Interim: if only upload shaping is supported for now, log a warning when
   download_speed is set and document the limitation, so results are not silently
   misinterpreted.

Happy to open a PR for either approach if useful.