decision about using pool-id 0 as UNUSED or first pool or INVALID

the current implementation and schema upgrade uses pool-id 0 value as default.

all leases currently stored in lease storage have pool id 0.

motivation:

1. subnet id 0 is the default so I think pool id should follow.
2. the SubnetID type is uint32_t so PoolID is uint32_t also in Kea code.
3. -1 for pool id is not that portable (I am not sure all backends have the same support for the same data types - int32/uint32/int64/uint64 and choosing a value in kea code to int32_t to -1 would be interpreted by some of the backends as a large number (for unsigned) or even a middle value for uint64).
4. -1 would also cause migration issues if we decide to add support for uint64_t in Kea code (a large uint32_t value aka -1 will have a different large value for uint64_t which will make the old value a valid pool id, which will cause some kind of confusion).

using 0 has some flexibility:

5. 0 can mean UNSET and valid pool ids start from 1 (first pool index in a subnet), making the distinction between unset/unused and explicitly set.
6. 0 can be the first pool index that must exist (there can not be a lease assign that has been allocated in a subnet with no pools), making pool id 0 always a valid pool id, even if not accurate (before explicit lease update) if there are more pools. in this case, pool id is a bucket for all leases that have not been updated.
7. subnet stats are inaccurate when a subnet is added/removed and all subnets are recounted. the same could apply to pools. this makes all stats eventually consistent, and with each lease being updated, the stats converge to real values. this is acceptable because these are only stats.
8. pool id is only used in stats, and no kea query is using a specific pool id, so this can be changed at any time, in contrast to the subnet ids which are used in queries.
9. making pool id mandatory would make current configurations unusable, so a default value MUST be used, so 0 looked like the best candidate. there might be some huge configurations there with hundreds or thousands of subnets, each with one or more pools. this would make the config upgrade hard to manage, even if automated.
10. as mentioned before, there are 3 types of state in which an pool ID might have: VALID/ACCURRATE (after a lease update and before any config change related to subnets or pools), UNUSED (before any lease update and before the schema upgrade to 2.3.8) and INVALID (after a config change related to subnets and pools but before a lease update). the third kind will always exist as the subnet id will always cause it, even if the pool id somehow avoids it, and I think we should not spend much time/effort to try to fix it. using pool id 0 as UNSET and starting from 1 as first pool index makes a distinction between UNSET and VALID, but as there will always be the INVALID state, we can omit this state also and use 0 as the first pool index.