[Enhancement] Add independent control for UDP GSO and GRO (--gso, --gro)

Problem Statement

Currently, iperf3 supports UDP Generic Segmentation Offload (GSO) and Generic Receive Offload (GRO) via a single combined flag: --gsro. While this is convenient, it forces both offloads to be active simultaneously.

Testing shows that while GSO (sender-side) is almost universally beneficial, GRO (receiver-side) can cause significant CPU saturation on the receiver depending on the hardware and kernel version. Currently, there is no way to benefit from GSO without incurring the receiver-side overhead of GRO.

Proposed Solution

I propose splitting the offload controls into two independent flags while maintaining backward compatibility:

1. --gso: Enables only UDP_SEGMENT on the sender.
2. --gro: Enables only UDP_GRO on the receiver.
3. --gsro: Remains as a legacy/convenience flag that enables both.

Technical Motivation & Test Evidence

Testing across different Network Interface Cards (NICs) reveals that a "one-size-fits-all" approach to offloading is suboptimal.

Test Environments

• Env 1: Intel X552 (10GbE) | Ubuntu 22.04 (Kernel 6.8)
• Env 2: Broadcom BCM57800 (10GbE) | Ubuntu 22.04 (Kernel 5.15)
• Env 3: Mellanox ConnectX-5 (25GbE+) | Ubuntu 24.04 (Kernel 6.17)

Comparative Data

Observations & Hardware Variance

• The Intel Bottleneck: On the X552, GRO is extremely "expensive," saturating the receiver CPU. Splitting the flags allows us to keep the 46% CPU saving on the sender (via GSO) without breaking the receiver.
• The Broadcom Stability: Unlike the Intel card, the Broadcom BCM57800 shows similar behavior whether using --gsro or --gso. While it doesn't suffer as much from GRO overhead, providing independent flags ensures consistent behavior across different testing toolsets.
• The Mellanox Throughput: On high-speed ConnectX-5 cards, GSO is the difference between hitting line rate (25G) or being CPU-bound at 18G. As with the Intel tests, using only GSO keeps the receiver from hitting the 100% ceiling.

Conclusion: Because different NIC models (Intel vs. Broadcom vs. Mellanox) handle offloads differently, users need granular control to avoid artificial bottlenecks during performance validation.

Observations

• GSO Efficiency: In all environments, GSO drastically reduced sender CPU load or allowed for higher bitrates by offloading segmentation to the NIC.
• GRO Bottleneck: In Environment 1 and 3, GRO caused the receiver CPU to hit 100% saturation. Being able to disable GRO while keeping GSO active allows for higher performance tests without receiver-side bottlenecks.

Implementation Details

The changes involve:

• Updating iperf_api.h/c to include the new boolean flags in the test settings.
• Modifying the logic in the UDP stream handlers to check for --gso or --gro specifically.
• Updating documentation in iperf3.1 (man page).

Use Cases

• Precise performance tuning for high-speed (10G/40G/100G) networks.
• Isolating kernel stack vs. hardware offload issues during debugging.
• Supporting environments where only the sender hardware supports offloading.