[ISC-support #13437] Have vendor option processing made accessible to classification for subnet allocation

There's a chicken-and-egg problem. Option 43 syntax is vendor specific, so Kea allows adding option definitions to client class, so you can have vendor dependent parsing. However, to use this the packet needs to be classified first. But what if you want to use values in option 43 suboptions to assist with classification? Parsing them using "substring" relies on all client packets having the same vendor options/suboptions in the same order - this can't be guaranteed.

---

This feature request originated in Support ticket https://support.isc.org/Ticket/Display.html?id=13437

The use case from this production environment is from the same environment as presented in #149 (closed).

In this instance, additional classification is desired, based on the vendor options.

A workaround was created adding further processing to an already-existing custom hook with callout at pkt4_receive.

The processing flow within this hook was extended to add something along the lines of:

Pkt4Ptr pkt;
callout_handle->getArgument("query4", pkt);
OptionPtr option43 = pkt->getOption(43);
OptionPtr option2 = option43->getOption(2);

if (option2) {
    std::string payload(option2->getData().begin(), option2->getData().end());
    if ((payload == "MTA") || (payload == "EMTA")) {
        pkt->addClass("MTA");
    }
}

(Note that the above syntax is example-only and not tested in production)