more lenient parsing of DHCPv6 option 16

kea-dhcp6 currently enforces a format of length-value pairs when parsing vendor-class-data and vendor-option-data fields of option 16 and 17, respectively. This is not mentioned in RFC 8415, nor does it recommend against, and so the decision is left to the implementer:

      vendor-option-data   Vendor options, interpreted by
                           vendor-specific code on the clients and
                           servers.  A variable-length field (4 octets
                           less than the value in the option-len field).

The mentioned option-len field is the length of the entire option. That is also checked against, and that behavior is RFC-compliant and should be left as it is. Not only is it required, but it is also sufficient to determine the size of said data fields.

The suggestion is to not check against the inner length i.e. inside the data fields. There are considerations to be made whether it should be done:

• generally
• on a vendor-by-vendor basis
• with a configurable boolean setting as "support-broken-clients", "lenient-option-parsing", and so on.

See the ongoing discussion for more clues: RT#18187