DHCPv4 fixed fields, such as boot-file-name, value precedence order is inconsistent with options

There are three "fixed" fields next-server, server-hostname, and boot-file-name sent in DHCPv4 ACKs. They are not handled like configured options, rather they are handled in Dhcpv4Srv::setFixedFields(). This function cycles through all classes associated with the client's packet, in the order they are associated, and uses the last value for a given option found. This is exactly the opposite of what we do for configured options. For those we evaluate the classes in the associated order BUT we use the first value for a given option. For example, using the following config:

   "client-classes": [
    {
        "name":"one",
        "boot-file-name":"one.boot",
        "option-data": [
        {
           "name": "domain-name-servers",
           "data": "1.1.1.1"
        }]
    },
    {
        "name":"two",
        "boot-file-name":"two.boot",
        "option-data": [
        {
           "name": "domain-name-servers",
           "data": "2.2.2.2"
        }]
    }
    ],

    "subnet4": [
    {
        "id": 1500,
        "subnet": "178.0.0.0/8",
        "pools": [ { "pool": "178.16.1.0 - 178.16.1.255" } ],
        "reservations": [
        {
            "hw-address": "08:00:27:25:d3:f4",
            "client-classes": [ "two", "one" ]
        }]
    }],

The value for boot-file-name will be "one.boot" and doman-name-servers will be "2.2.2.2". If we associate the classes in the reverse order, (i.e "one", "two") then I get "two.boot" and "1.1.1.1". This is inconsistent and in my opinion, broken. They should do it the same way. In this case, fixed fields should follow options behavior. The options ordering for classes is clearly documented in the ARM:

https://kea.readthedocs.io/en/latest/arm/classify.html#client-classification-overview