Refs #984: sendpacket: avoid endless retries on ENOBUFS/EAGAIN

[d3156]

Refs #984.

Problem

When using the PF_PACKET injection method, sendpacket() may enter an endless retry loop if send() keeps returning ENOBUFS or EAGAIN continuously (e.g., with very large frames or under sustained buffer pressure). This results in 100% CPU usage and tcpreplay never progresses to the next packet.

Change

Introduce a bounded retry loop for transient ENOBUFS/EAGAIN failures:

• Add a small sleep on retries to avoid busy-looping and unnecessary kernel load.
• Stop retrying after max_retry_count attempts and return an error so tcpreplay can continue with the next packet.

How to test

1. Build tcpreplay from this branch.
2. Replay a pcap that triggers persistent ENOBUFS/EAGAIN on PF_PACKET.
3. Verify that tcpreplay no longer hangs in an infinite retry loop and instead proceeds (or reports failure) after the retry limit.

Values are currently hard-coded and can be made configurable if maintainers prefer.

[fklassen]

Thanks for this — the fix is merged, folded into #996 with a couple of review fixups on top:

• usleep(0) doesn't actually sleep on any target libc, so it wasn't preventing busy-looping as intended; replaced with a real usleep(100) backoff, matching the existing convention in src/common/txring.c.
• Added an explicit sendpacket_seterr() call when the retry cap is hit, so callers get an accurate error instead of a stale/empty buffer.
• Minor style cleanup (label indentation, trailing whitespace).

Merged in 426706a on Bug_#984_endless_retries_on_ENOBUFS_EAGAIN, and #984 is closed. Closing this one as superseded — credited in docs/CREDIT and docs/CHANGELOG. Thanks again for the fix!