Want implementation of Large Receive Offload

LRO refers to a host OS or NIC's ability to coalesce multiple packets together, with the aim of reducing the amount of packets processed per second (and delivering larger contiguous data segments to TCP stacks). This can apply to stream transports like TCP, or fragmented UDP reassembly (which is not really applicable on the current dataplane).

Part of the performance boost seen from https://github.com/oxidecomputer/opte/pull/614 comes down to the fact that we are abusing the wider underlay MTU to achieve a form of send-side LRO. Fewer packets transit OPTE (eliding identical parse/decision cycles), and fewer packets are handed upstack to guests/zones.

We have some different options here:

• Attempt optimistic LRO before processing by OPTE. This reduces the cost on packets crossing OPTE (only one parse/process/modify), but when flowstats come around we might need to take some care to prevent the packet_in numbers from surprising customers.
• Attempt optimistic LRO after processing by OPTE. This has minimal impact on stats

In both cases, illumos zones behave well when served larger packets (i.e., NTP and Nexus zones today) and the setup work for #614 means that viona can always accept and split an oversize/receive-offloaded TCP packet, even if the guest cannot.

This will be blocked on having full packet chain Rx from mac (IPD45).

Start by reading IPD45's full packet-chain Rx work and PR #614, since this issue is explicitly blocked on packet-chain Rx from mac. Compare optimistic LRO before and after OPTE processing, including the effect on flowstats and packet_in counts. Done means LRO works with the existing viona oversize-packet handling and remains compatible with illumos zones.