OpacityIndex/ServerHeightMap: Memory usage and performance optimizations

[Niko-sk2x]

Current ServerHeightMap implementation has no upper memory usage bound, the more complicated the terrain, the more memory it will use. This also means that each block update causes update in ServerHeightMap which can be potentionally expensive, this slows down setting blocks and thus terrain generation as a whole.

The first part - not keeping the whole thing loaded

The idea is to actually store the data on disk and keep only the top entry that references unloaded cube in memory - that would be UnloadedSurfaceTracker.

For the loaded parts - heightmap would be tracked in similar way as vanilla does it - placing a block above heightmap would move it up, breaking the top block would invalidate it, causing recalculation next time some code needs to get it. Unloading a cube will automatically update the heightmap and loading a new one will work the same as placing a block.

The second part - make updating only parts of ServerHeightMap easy

This should be done only after the second part is done. The plan is to use region-like format (using RegionLib) to store the heightmap data structures in segments of synamic size with some allowed size range. Then some additional on-disk data structure would be needed for fast lookup of segmentNumber->segmentLocation.

At the time of writing this, it's still far into the future, and I'm not exactly sure how it could be implemented.

[Niko-sk2x]

After some initial calculations - doing that means at least 2MB additional size for a newly created world. Is that acceptable? It may make the world 2x bigger on-disk than vanilla.