test: add data compatibility test

[MichaelScofield]

I hereby agree to the terms of the GreptimeDB CLA

What's changed and what's your intention?

Add a test for data files compatibility. See the readme for more details.

Checklist

• I have written the necessary rustdoc comments.
• I have added the necessary unit tests and integration tests.
• This PR does not require documentation updates.

Refer to a related PR or issue link (optional)

#1730

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (50d16d6) 85.65% compared to head (939355d) 84.80%.
Report is 38 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3109      +/-   ##
==========================================
- Coverage   85.65%   84.80%   -0.86%     
==========================================
  Files         859      880      +21     
  Lines      140757   143115    +2358     
==========================================
+ Hits       120571   121374     +803     
- Misses      20186    21741    +1555     

[sunng87]

I'm not a big fan of checking-in blobs. Can we use a prebuilt docker image for that?

Checking-in blobs will increase the repo size and make clone and fetch slow. We will be running these tests for every future version, which means more blobs to be added to repo. I'm afraid this approach won't be scalable.

[MichaelScofield]

@sunng87 Those binary files are not large for now, only 2.8MB compared to total repo size 76MB. We can keep this size small.

Besides, there always should be only one piece of data that are tested against the newly built greptimedb. Should there be any breaking changes, the data need to be generated again (using current codes).

Finally, a pre-built image for this simple purpose is kind of overkill. To make it worse, the downloading and running of the image will increase the github CI time a lot.

So I think at this early stage, let's keep it simple and straightforward. If there're more complex compatibility testing cases, we consider the other way.

[waynexia]

I'm negative about this either. Those files are likely to change from version to version, I prefer to track those fixtures elsewhere, like a pre-build image or a separate repo like https://github.com/apache/parquet-testing, where

• Updates to fixtures are aggregated
• Won't fold the code repo
• It's easy to maintain different versions and formats

[MichaelScofield]

I think running compatibility test in github CI is a must, it tells us which PR has breaking change immediately. Another repo or pre-built image are overkill for this, complicate things a lot. Not to metion the time cost. I'm planning refer to how databend does the compatibility test (see https://github.com/datafuselabs/databend/tree/main/tests/fuse-compat), that:

1. download the latest binary from github release(the "old" version)
2. build a binary from current source(the "new" version)
3. start the old binary, insert some data into it, kill
4. start the new binary, set its data home to the old, query some data to verify the compatibility

WDYT @sunng87 @waynexia @killme2008 @fengjiachun

[waynexia]

This looks good to me. Generating data on testing can make this test more flexible, by this way we have the ability to check the compatibility between two arbitrary versions.

[sunng87]

Sounds ok to me. We can start from this approach and see if it scales

[MichaelScofield]

@sunng87 @waynexia PTAL

[sunng87]

other parts have been looking good to me

[MichaelScofield]

@waynexia PTAL

[waynexia]

Mostly LGTM