Kea should honor PD length hints if possible

The issue has been brought up in support#18537.

The RFC8415 has the following text:

Client MAY include the IA Prefix option encapsulated within the IA_PD option,
with the "IPv6-prefix" field set to 0 and the "prefix-length" field set to
the desired length of the prefix to be delegated.  The server MAY use this
value as a hint for the prefix length.

Kea does not support this mechanism yet.

Here's how the situation could be improved: When configured with a certain address space (e.g. /48), Kea is told to split it into specific length (e.g. /56) and delegate however many prefixes from it. This part is fixed and it's not going to change due to a problem with long term fragmentation reasons. To visualize this, imagine a case of /48 pool intending to be split into 256 /56 prefixes and very liberal policy accepting all prefix hints. In the extreme case clients could request 256 of smallest prefixes available, i.e. each consisting of a single address /128. Those prefixes could be distributed across the address space in a way that it would no longer be possible to allocate any /56 prefixes, because there would always be some /128 in place. This extreme case is an exaggeration, but similar problems could happen on a smaller scale. Also, finding "holes" is allocated address space is a hard problem if the allocations are not of the same size.

Saving said that, here's what possibly could be done to improve the situation:

1. if there are pd-pools defined with different lengths, e.g. /56, /60 and /64, Kea could pick the right pool and allocate from it. Within any given pd-pool there would be only allocations of the same length, but from the client's perspective, its request to get specific prefix length would be honored, as long as it's /56, /60 or /64.

2. In practice, delegating prefixes longer than /64 (65 or more) do not make any sense. The CPE requires PD to use SLAAC on its LAN facing segment. SLAAC to function requires exactly /64 prefix. If the device gets prefix longer (e.g. /60), it can easily split it into more sub-prefixes and only use one or some of them. In practice, this translates to a common practice of using /64, /60, /56 and very sporadically /48.

3. It is somewhat feasible to think about allocation policy that when configured with pd-pool with length X, to also accept requests for X-Y and then allocate 2^Y prefixes. This could possibly work for small Y values, e.g. when configured with pool of /64s, a request for /63 could be accepted with 2 allocations. I'm not sure if such a mechanism would give us much. On the other hand, it could seriously complicate the allocation engine.

Point 1 above looks like the best choice for improving the situation here.