Resolve "CA returns number overflow on ipv6 stats"

Closes #3068 (closed).

• acf7cbd4 fix shadowed member

  data.cc: In member function ‘virtual void isc::data::MapElement::toJSON(std::ostream&) const’: data.cc:919:51: warning: declaration of ‘m’ shadows a member of ‘isc::data::MapElement’ [-Wshadow] 919 | const std::map<std::string, ConstElementPtr>& m = mapValue(); | ^ In file included from data.cc:9: ../../../src/lib/cc/data.h:769:44: note: shadowed declaration is here 769 | std::map<std::string, ConstElementPtr> m; | ^

• 24e9c3ed add bigint deserialization unit tests

• da10ffa5 switch bigints to the checked variant

  Kea needs to gain knowledge of big integers overflowing and underflowing in various places in code such as when deserializing integers where it's important to know if the recipient can hold the value, and if the value is accurately represented.

• 2c03a737 add unit tests for checked bigints

• 29530870 add bigint support to the Element deserializer

• 0b87cc1d fix prefixesInRange after uint128_t was moved to checked_uint128_t

• 22fe0f63 add comment about code obsolescence

• 8040f6c0 add ChangeLog entry

My initial idea to do a strcmp on the number being parsed and on INT128_MAX doesn't work at all. As it turns out, it's not lexicographical order that's needed, but numerical order. So I turned to trying to cast to int128_t after the cast to int64_t. The impact should be minimal, considering that most integers fit on 64 bits.

I was able to get a successful response for this statistic on a ::/1 subnet.

    "subnet[1].total-nas": [
      [
        170141183460469231731687303715884105728,
        "2023-10-02 17:47:07.504239"
      ]
    ],