Sanity check VLAN offload on packet drop

Check that VLAN offload is not broken by previous packet drop

PMDs tend to maintain offload state in software for various reasons, and in the case of VLAN offload there is a possible pitfall when a packet is dropped due to lack of room for descriptors: if this packet enables VLAN offload, the PMD must make sure that its software state for that offload is rolled back, otherwise the next packet with exactly the same VLAN TCI will make the PMD assume that the HW is already set for this offload and nothing has to be changed. In the latter case, the offload will be wrong.

The test tries to reproduce this corner case by sending two packets with identical VLAN IDs, the first one being wittingly sliced into more mbufs than the number of descriptors in Tx ring and thus going to be dismissed.

Prepare TEST_ETHDEV_INITIALIZED state.
Obtain the source Ethernet address.
Fill in offloads needed by the test regardless whether these capabilities are supported by the current RTE release or not. Preserve automatically added device offloads.
Sort out the set of capabilities to use valid Tx mode configuration.
Prepare TEST_ETHDEV_RX_SETUP_DONE state.
Choose a reasonable number of Tx queue descriptors and set sufficient payload length for the first packet so that it can be sliced into as many segments as how many descriptors the queue has, plus one.
Adjust the traffic template and make its copy.
Setup the only Tx queue.
Randomly select VLAN ID.
Describe 'send transformations' so that it is possible to generate traffic pattern aware of VLAN offload on the next step.
Prepare the first packet mbuf.
Query header length fields of the packet; this result will stay valid for the second packet, too.
Derive Ethernet payload length of the packet; this result will stay valid for the second packet, too.
Fix MTU on both ends if required.
Prepare TEST_ETHDEV_STARTED state.
Slice the first packet mbuf into as many segments as how many descriptors the transmit queue has, plus one, so that the packet is going to be rejected.
Try to send the first packet and make sure it gets dismissed. Don't validate the packet since Tx prepare API will reject it too early without any chance to face Tx burst API and check VLAN TCI rollback behaviour
Prepare the second packet mbuf.
Create an Rx CSAP on TST host according to the template.
Start capturing traffic with the pattern prepared.
Ensure that interface is UP on Tester side
Validate and send the second packet and make sure it does not get dismissed.
Stop capturing traffic.
Verify the number of matching packets received.

Parameters:

tmpl	Traffic template

vlan_on_packet_drop