More efficient serialization for bitmap segments

[jaspervdm]

This PR introduces a new type BitmapSegment that can be converted back and forth into a Segment<BitmapChunk>. It provides a more efficient (de)serialization than the Segment by choosing different strategies depending on the occupancy of the bitmap in the range. This is achieved by splitting the segment up in blocks of 2^16 bits (BitmapBlocks). If a block has less than 4096 positive indices, we serialize a list of positive indices as unsigned 16bit integers. If a block instead has less than 4096 negative indices, we serialize a list of negative indices as unsigned 16bit integers. In other cases, we serialize the full bitmap bytes directly.

TODO:

• We can speed up the conversion between the two types by manipulating the storage of the internal bitvecs directly, using an unsafe block. Is this something we want to do? Can be done in a future PR
• Check whether the current tests are sufficient

[antiochp]

👀

[antiochp]

Bitmap chunks are 1024 bits long.
Segments are variable length (based on height).
We flip serialization strategies at 4096 bits.
So does this mean that for some segment sizes/heights we only ever use the positive/negative indices and never fallback to the bitmap representation?

[jaspervdm]

In theory yes, but such segments are currently not allowed. Per the RFC, the minimum height of a bitmap segment is 9.

[antiochp]

• We can speed up the conversion between the two types by manipulating the storage of the internal bitvecs directly, using an unsafe block. Is this something we want to do?

We can always revisit this later - I would not optimize like this yet.

[antiochp]

This looks good.
Minor comment about the positive/negative/raw_bytes magic numbers.