feat: Add bendsave which can backup and restore databend data

[Xuanwo]

Signed-off-by: Xuanwo [email protected]

I hereby agree to the terms of the CLA available at: https://docs.databend.com/dev/policies/cla/

Summary

This PR will add bendsave: the DR tool for databend that can backup and restore databend data.

The RFC could be seen at: https://docs.databend.com/guides/community/rfcs/disaster-recovery

This PR tested in this way:

• Build a new databend query node with tpch data.
• Perform tpch sqllogictests.
• Run backup.
• Destory all data entirely, remove the metasrv's data.
• Run restore.
• Perform tpch sqllogictests again.

Tests

• Unit Test
• Logic Test
• Benchmark Test
• No Test - Explain why

Type of change

• Bug Fix (non-breaking change which fixes an issue)
• New Feature (non-breaking change which adds functionality)
• Breaking Change (fix or feature that could cause existing functionality not to work as expected)
• Documentation Update
• Refactoring
• Performance Improvement
• Other (please describe):

---

This change is 

[drmingdrmer]

• Build a new databend query node with tpch data.
• Perform tpch sqllogictests.
• Run backup.
• Distory all data entirely, remove the metasrv's data.
• Run restore.
• Perform tpch sqllogictests again.

Before conducting a thorough review, I have a question:
Is the second pass of SQL logic tests identical to the first pass?
Does it focus on reading the restored data or executing a new test on a recovered metadata/data set?

[Xuanwo]

Is the second pass of SQL logic tests identical to the first pass?

Yes, exactly the same.

Does it focus on reading the restored data or executing a new test on a recovered metadata/data set?

I'm trying to run a new test on a recovered metadata/data set to ensure that all the data has been restored correctly.

I chose the TPC-H test for this since we are only executing queries and not inserting new data or performing DML operations, which do not need to be tested again.

[drmingdrmer]

Reviewed 24 of 24 files at r1, 4 of 4 files at r2, all commit messages.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @dantengsky, @everpcpc, and @sundy-li)

[drmingdrmer]

An excellent PR! Clean and concise!

[Xuanwo]

An excellent PR! Clean and concise!

70% of me thanks you, and the remaining 30% (most on docs) comes from Claude 3.5 sonnet.

[dantengsky]

Looks good to me.

As we continue improving this feature, here are a few considerations:

Given that the table data could grow quite large, we should probably give some extra thought to the efficiency of backup and restore operations. If I understand correctly, the current approach involves periodically backing up data from A to B, then restoring it to C, with B potentially storing multiple versions.

Even if we avoid redundant data objects across those versions at B, this could still lead to significant additional storage costs. The efficiency of restoring from B to C might also negatively impact the RTO.

Additionally, since the backed-up data already includes time travel data, this might raise questions about the necessity of multi-version backups. The vacuum operation on backups could introduce complexity in both implementation and maintenance.

[Xuanwo]

All CI passed. I'm going to merge this PR now.