VLAN'd NICs used as underlay devices result in untagged frames

While testing some stlouis changes around MEOI updates, I attempted to use a VLAN tagged VNIC as one of my underlay devices. This had some fairly strange output as seen by the receiving end.

• The recipient's src/dst MAC addresses and IP addresses were correct,
• The Ethernet frame was not VLAN tagged.

All normal traffic directed over the VLAN behaved as expected (e.g., correctly tagged and delivered to the target VNIC).

This appears to come from our entrypoint in the Tx path, str_mdata_fastpath_put. Ordinarily, a packet should arrive at dld_wput, and would then in fact be processed by str_mdata_raw_put, which inserts the VLAN tag itself. DLS has instructed MAC not to fill in VLAN tags during link plumbing using MAC_UNICAST_TAG_DISABLE/MCIS_TAG_DISABLE. The catch is that a) that method is likely slower, b) it is static and c) it removes the hint parameter we can use when we already have a consistent flow hash for a set of packets.

If we want to make use of VLANs for any reason, we'll need to reconsider the tx pathway (or at least bake these considerations into how we'd send from a mac_flow_t in IPD45).

Start at the Tx entrypoint str_mdata_fastpath_put and compare it with dld_wput and str_mdata_raw_put. Inspect the MAC_UNICAST_TAG_DISABLE and MCIS_TAG_DISABLE behavior, including the hint parameter, then consider the IPD45 tx pathway. Done means VLAN-tagged underlay traffic preserves its Ethernet tag without regressing normal VLAN delivery.