[pixels-cpp] Use flatbuffers instead of protobuf for serialization

[whzruc]

Flatbuffers use a different way to handle data in memory.Flatbuffers allows user to directly access the serialized data in memory without any parsing or extra memory allocatin(zero-copy access).
In the previous version of pixels-cpp, we used Protobuf and found that data serialization was a major performance bottleneck. In this work, we replace Protobuf with FlatBuffers for serialization and conduct comprehensive performance evaluations.

[whzruc]

Part 1 Implementation of flatbuffers serialization

First, I define a new file named pixels.fbs to describe the pixels file format.
then I replace the proto rules in pixels-common/CMakeLists.txt with flatbuffers and update the Makefile to support flatbuffers compilation.
Then I rewrite the PixelsReaderImpl and PixelsWriterImpl to support flatbuffers-based serialization.
Flatbuffers requires a global FlatbufferBuilder(the variable fbb) to recursively build file. The files are written block by block in units of rowgroup.Fbb.finish() will be called after a rowgroup is written,which indicates all columnchunk offsets and statiscal information have been serialized and flushed into the rowgroup. After all rowgroups are written, writeFileTail will assign a fileTail as the root object in flatbuffers.

[whzruc]

Part 2 Optimization of Pixels-cli LoadExecutor

After I complete the reader and writer, I firstly add some tests in tests/writer/PixelsWriterTest.cpp. All tests pass successfully.However, the pixels-cli LoadExecutor still needs to be extended to support loading Flatbuffers-based files, as the Java version of pixels-cli does not currently provide a FlatBuffers loader.
1.Fix bugs
I find several remaining bugs in the previous version of IntColumnWriter and LongColumnWriter, then I fix and test to ensure the correctness.

2.Parallelism loading
The current loaders does not support multi-threaded loading, I add a parameters named c and implemented parallelism loading support. However, the performance improvement appears to be limited.

3.Columnchunks Parallelism
The role of PixelsWriterImpl::writeColumnVectors is to write column chunks.
I evaluate a multi-threaded implementation (based on std::future) against
a single-threaded version and observe a similar issue to the one encountered
in parallel loading: the performance improvement from parallelism is limited.

[whzruc]

Part 3 Evaluation
I test the flatbuffers vs protobuf on clikcbench-pixels-e0-24ssd with 96 threads.Here is result.

Key finds:
I report the median performance over three test runs and observe that Flatbuffers consistently outperforms protobuf, especially for Q20.
This behavior can be explained by the nature of Q20: it is a point query with high selectivity and returns no results.In such cases, the executor must scan all rowgroups to determine that no matching data exists, effectively degenerating query execution into a full metadata scan. As Flatbuffers significantly reduces metadata access overhead, it provides greater performance benefits for this workload.

It can be seen from the analysis of the flame diagram, the google::protobuf serialization dominates cpu time, primarily due to the parsing of ColumnChunkIndex, RowGroupFooter and PixelStatistic.