fix(containers): aggregate network stats over all container interfaces (#3669) - #3670

Description

Fixes #3669.

DockerStatsFetcher._get_network_stats() read the container network counters from a
single hardcoded interface:

eth0_stats = self._streamer.stats.get('networks', {}).get('eth0')

The Docker stats endpoint returns one entry per container interface, so a container
attached to several networks (docker network connect, or several networks in a Compose
file) gets eth0, eth1, … and everything past eth0 was silently dropped. Reported
RX/TX for those containers was too low.

The method now sums rx_bytes/tx_bytes across all interfaces. Its output contract is
unchanged: same keys, same types, same units.

Two deliberate choices, as discussed in the issue:

• lo is excluded. The Docker daemon does not normally report loopback in networks,
  but Docker-API-compatible runtimes have been observed to, and loopback traffic would
  massively inflate the totals.
• Interfaces with missing counters are skipped, not fatal. Previously a malformed
  eth0 aborted the whole method; now one malformed interface among several no longer
  discards the valid ones. None is still returned when nothing usable remains, so
  --network host containers (no networks key) behave exactly as before.

On the decision point raised in the issue

The issue asked not to decide alone between (a) leave as is and (b) clamp the delta
to zero, given that attaching/detaching a network between two samples changes the
interface set and can produce one negative rx/tx delta.

This PR implements (a), for two reasons:

1. Negative deltas are already reachable today on container restart, when the counters
   reset. (b) would silently swallow that pre-existing signal too, which changes behaviour
   for a case that is not in the scope of this issue.
2. (b) hides a real counter discontinuity rather than reporting it. If the glitch turns
   out to matter in practice, clamping is better addressed once for all cumulative
   counters than locally here.

Happy to switch to (b) if you prefer.

Tests

New file tests/test_plugin_containers.py, 9 cases, pytest style to match the sibling
test_plugin_*.py files. DockerStatsFetcher.__init__ opens a live stats stream, so the
instance is built via __new__ with the two attributes the method reads injected.

Verified the tests actually pin the bug — against the unpatched docker.py, exactly the
two cases that target it fail and the seven regression guards pass:

FAILED tests/test_plugin_containers.py::TestDockerNetworkStatsAggregation::test_two_interfaces_are_summed
        assert 100 == 150
FAILED tests/test_plugin_containers.py::TestDockerNetworkStatsRates::test_rates_use_the_summed_counters
        assert 60 == 110
2 failed, 7 passed

With the patch: 9 passed.

Regression run

Full suite before and after, same machine (Windows 11, Python 3.14, 1 running container):

before: 57 failed, 571 passed, 106 skipped, 15 errors
after:  58 failed, 579 passed, 106 skipped, 15 errors

The 72 pre-existing failures/errors — test_restful.py, test_xmlrpc.py, test_mcp.py,
test_browser_restful.py, test_amp_secure_popen.py, test_webui.py, test_perf.py, all
server/WebUI tests that need a chromedriver and a POSIX socket — are identical line for
line before and after. The 9 new tests account for the passed count.

The single delta is test_memoryleak.py::test_memoryleak_no_history
(assert memory_leak < 15000, got 15524). It is not caused by this change:

• The file passes on its own with the patch applied.

• Its measurement is unstable on this machine, and it exceeds its own threshold on
  unpatched develop. Three runs each, reading the value the test itself logs:

  run	unpatched develop	this branch
  1	12 391 B	16 734 B
  2	7 948 B	20 268 B
  3	32 480 B ❌	6 718 B
  mean	17 606 B	14 573 B

  The unpatched spread is 7 948 – 32 480 B, a 4× range against a hard-coded 15 000 B
  threshold, and the unpatched maximum is the largest of all six runs.

• Isolating the changed method removes the ambiguity. Driving both implementations
  200 000 times under tracemalloc with the same single-interface payload:

     old (eth0 only): retained after 200,000 calls =  688 bytes  (0.0034 B/call)
    new (aggregated): retained after 200,000 calls =  656 bytes  (0.0033 B/call)
  

  Neither retains anything — that residue is tracemalloc's own bookkeeping — and the new
  form retains marginally less. The memory-leak test performs ~13 calls per run, so the
  per-call difference is well under a byte.

Flagging the threshold separately since it is unrelated to this PR: on a machine with any
background load, test_memoryleak_no_history looks like it can fail on a clean checkout.
Happy to open a separate issue if that is useful.

ruff format and ruff check are clean on both touched files. rstcheck NEWS.rst reports
the same 8 pre-existing issues before and after, shifted by the one added line.

Branches

Applied to develop. I re-verified the branch parity the issue asked about rather than
assuming it: glances/plugins/containers/engines/docker.py has blob SHA
c818def749329c9b2d00171c43cb2f2739fac5f4 on both develop and develop-v5, so the
cherry-pick to develop-v5 is clean. Say the word and I'll open the companion PR.

Resume

• Bug fix: yes
• New feature: no
• Fixed tickets: Fix container network accounting: sum all interfaces, not only eth0 #3669