VENDOR_CLASS_ not assigned if kea-dhcp4 receives two or more options of code 60

If kea-dhcp4 receives two or more options of code 60, it concatenates them under a single option which is then parsed as a byte-array rather than a string. Not a confirmed use case by any stretch, but potential clients sending two options might theoretically expect to be treated as two vendors simultaneously rather than as a single vendor with a kludgy ID. VENDOR_CLASS_ is not assigned at all to the packet as it usually is when a single option is received. Arguably, it would be better if all vendor classes were assigned or at least one of them.

• Here is how Kea logs a 4-length option 60: type=060, len=004: "1234" (string) followed by DHCP4_CLASS_ASSIGNED [...] client packet has been assigned to the following class(es): ALL, VENDOR_CLASS_1234, UNKNOWN
• Here is how Kea logs two 4-length options with values 1234 and 5678: type=060, len=008: 31:32:33:34:35:36:37:38 followed by DHCP4_CLASS_ASSIGNED [...] client packet has been assigned to the following class(es): ALL, UNKNOWN

Tested on current master f390f5ac, but happens on 2.2.0 as well.

Capture, config, and log, that help in observing the issue:

• capture.pcap
• kea-dhcp4.conf
• kea.log