Limit minimum size of class 3 connections to 16 bytes for both directions

A CIP class 3 explicit connection has, according to the specification, a minimum PDU size of 16 bytes. Smaller connection sizes were previously allowed, but not functional. With this ticket, connection sizes lower than 16 bytes will now be actively rejected by the adapter.

A class 3 connection request consists of the following elements

• Sequence Count 2 byte
• Service Code 1 byte
• Request EPATH
  • [Electronic Key Format4 8 bytes]
  • Application path (padded EPATH) 5..17 bytes (ClassId, InstanceID, [AttributeId, MemberId])
• Request payload 0..

A class 3 Response consists of the following elements

• Sequence Count 2 bytes
• Service Code 1 byte
• Padding 1 byte
• Response payload
  • Status code 2.. bytes + Data 0..

This ticket brings further low-level changes in the encapsulation behavior, for instance:

• The SendUnitData encapsulation command is not replied to anymore in case the encapsulated packet is incorrect. Previously, error-replies were sent in case of invalid packets. Justification: SendUnitData-encapsulated CIP data consists of a CIP request or CIP response. If the ping-pong game goes off, it can be detected by the sequence count. SendUnitData itself does not have a request-response scheme, but provides a bidirectional packet-based data stream with sequence numbering (for detection of packet loss and duplicates, which both cannot occur with TCP and the sequence count will never be off). Anyway, the SendUnitData-encapsulation is not expected to fail dynamically if the client is implemented correctly. In case of encapsulation failure (packet too short, wrong CPF-format), we now just ignore the packet.
• The aulSenderContext header field of the SendUnitData command will now be populated by the EtherNet/IP adapter. Previously, we reflected the originator's value.
• If the originator is responsible for selecting the O2T or T2O connection IDs of a CIP connection and selects value 0, then we now determine a nonzero connection ID ourselves. This is mostly for better visualization of CT19 runs in wireshark. The change has low risk, since we rely on originators using the connection IDs from the FwOpen response unconditionally. In fact, zero is a valid connection ID which could also have been selected properly by the client.