Add boot file selection for Kea

[Kreeblah]

I would like to use Kea, but it would be good to be able to select which boot file is served. So, I implemented this. However, it has some downsides and I imagine will need some revisions before it's ready to be committed.

The biggest downside is that it moves the location of the default boot file, so it is a breaking change. I did this because it seems that the Kea config doesn't allow client classifications (which seem to be the only way to use conditional statements) directly in the subnet4 block.

I've also only tested this with one subnet, but I have designed it so that I expect it should work with multiple subnets, and select boot files appropriately. But, I will probably need some help with that testing.

I could also use assistance in testing the x86 UEFI boot process, as I don't actually have any UEFI-based x86 machines that support network booting. The code I used to identify 32-bit UEFI machines does match the RFC, though, so I don't see any reason why it wouldn't work. I just haven't been able to personally verify it. I have, however, been able to verify booting x64 UEFI and BIOS systems through payloads configured with this code.

[AdSchellevis]

@Kreeblah I have been working on some of the options in kea, but so-far all of this seems to be highly confusing (and I don't have enough time to test most of this currently). I still have a branch here https://github.com/opnsense/core/tree/kea_custom_opt_pr7361 which originates from a previous PR (#7361)

I can rebase it to master for you and see if we can use this as a new starting point, but what I need from a code perspective are some "simple" configurations that work as examples so I can see if we can mold it into the work already done in some way.

Although I do expect your code works, it's likely not very scalable if people need other options as well. An option could be to predefine some "standard" client classes which can then be used in custom option sets, but that's just thinking out loud, without a proper plan yet.

[Kreeblah]

You're right that this isn't very portable to other options. I pretty much designed it just for this one.

Having read your comments on the other PR, I'm increasingly thinking that that scoping discussion is probably necessary. My use case here is probably more complex than most (even though, on the face of it, it seems like it shouldn't be, it still uses Kea's Turing-complete tests, and they reference each other), but it's not really able to be covered by that other PR. I'm also unsure how common other use cases are that wouldn't be captured by the techniques either of these PRs have used. Really, I've only specifically worked with option 43 back when I ran a Unifi controller and didn't have it at the unifi hostname (which is the alternative default for their clients if option 43 isn't set) and option 93 (for network booting).

So, if it'd be alright with you, maybe I could open an issue to discuss scoping and requirements before proceeding further? I'd want to take some more time to get more familiar with the Kea documentation (so, that'd take a bit; it's quite extensive) and research other common use cases for people using DHCP options to try to understand what might be things that people could be likely to ask about.

My own time is a bit limited at this exact moment, but I should have more available in a few weeks to start doing research and organizing it for creating an issue.

[AdSchellevis]

@Kreeblah take your time, there's no rush here. We'er still seeking a way to offer more flexibility without having to rewrite the world, a scoping discussion in a new ticket might help indeed. Kea's configuration format so-far seemed to be a bit too flexible and "valid" configs don't always seem to deliver expected results (at least on my end).