Further reduce size

[willscott]

There isn't a full analysis of what's going on in the generated map. Some question that could lead to further reductions are:

• What is the cidr distribution of entries? If there are left-over /32's, are they really relevant?
• Are there places in the tree where a parent can be "pushed down" to reveal the redundancy of a child, or other more advanced transformations of that nature?

[willscott]

An example of this:

3735094419/32
3735094426/32

are both individual IPs announced by Germany.
In 3735094432/28, the /28 which contains both of these addresses,
the other 14 addresses are all 'ZZ', and not defined in the table anywhere. It is worth investigating why existing tree merging doesn't find that merge, since these meet the criteria I would expect it to find.

[willscott]

Tree rearrangement added in v0.2.1

[willscott]

With debugged tree work (in v0.3.0) uncompressed size is 2.0 MB.

There remain some needed pieces to the algorithm:

The main 'safeMerge' function only looks for nodes to merge at the top level of the tree, because it assumes that the /0 value is undefined, so that undefined space can be taken over by a merged node.
In subtrees, this assumption fails, because the parent node will define the empty space between children.