Block munging - "reserve space for growth"

[Kris Deugau]

In case of an allocation for a customer who may require more address space in the near future, and would like to keep that address space contiguous, allow a flag to be set on the original allocation (and the resulting free space blocks) that the free space immediately after the original allocation should be reserved to allow for this expansion.

Needs to have a method to manually return this reserved space to the free pool in case of running low on available free blocks.

Related to #8, and peripherally #7.

[Kris Deugau]

This is somewhat more important for IPv6, since it's officially recommended best practice.

Thoughts:

• Radio button defaulting to 1 bit (double), allow "no expansion" and 2 bits (quadruple)
• or a dropdown with 0-8? 0-4? (4 == 16x - can't see anyone knowing they'll need that much later but not yet, soon enough to matter... mostly.)
• expand routing column in freeblocks: value "e<n>" shows freeblock reserved for expansion, at <n> bits

[Kris Deugau]

(In [692]) /trunk

Start adding support for advisory "reserved block" assignments - when
creating a new assignment, flag an equal-sized block ahead or behind
to expand the assignment in the future. See #24.

• free block assignment
• guided assignment (still needs tweaking to dodge existing reserved blocks)
• note flagged blocks in free block list

[Kris Deugau]

(In [693]) /trunk

Exclude reserved freeblocks from guided assignment. See #24.

[Kris Deugau]

(In [695]) /trunk

Mostly fix up edge case of extending an IP pool allocation. See #24.

[Kris Deugau]

(In [696]) /trunk

Fix most of the edge cases for initPool() being called on extending a
pool. Callers would be responsible for cleaning up parent_id in the
case of eg "merge pools". See #24.

[Kris Deugau]

This seems to be complete in the case of "reserve an equal-sized space". Leaving open for a little while to ponder whether it's worth trying to support larger reserve spaces.

I decided that hiding the reserve block would only confuse things (based on reported preferred methods of netblock assignment), but the "guided" assignment will honour the reserved blocks. This could arguably have a flag available to consider reserved blocks, or consider reserved blocks if no other blocks are available.

[Kris Deugau]

(In [698]) /trunk

Missed an added field for adding a reserved block on a container on the
call to add the container's contained freeblock in r692. See #24.

[Kris Deugau]

(In [721]) /trunk

Fix bug adding new freeblocks after splitting a free block for a new
assignment; the free block that would be reserved would (almost?) always
be flagged, even when that wasn't requested.
See #24.

[Kris Deugau]

Resolving as "Feature Implemented"; there are refinements and enhancements possible but none critical.