[Feature] Support Cluster Snapshot Backup: support system table for cluster snapshot backup (part2)

[srlch]

What I'm doing:

Introduce two system table called cluster_snapshots and cluster_snapshot_jobs to provide a interface to get the cluster snapshot info.
This pr only impl the interface of these system but not involve the actually impl of ClusterSnapshot and ClusterSnapshotJob which should be introduced in the next pr.

Fixes #53867
#53867

What type of PR is this:

• BugFix
• Feature
• Enhancement
• Refactor
• UT
• Doc
• Tool

Does this PR entail a change in behavior?

• Yes, this PR will result in a change in behavior.
• No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

• Interface/UI changes: syntax, type conversion, expression evaluation, display information
• Parameter changes: default values, similar parameters but with different default values
• Policy changes: use new policy to replace old one, functionality automatically enabled
• Feature removed
• Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

• I have added test cases for my bug fix or my new feature
• This pr needs user documentation (for new or modified features or behaviors)
  • I have added documentation for my new feature or new function
• This is a backport pr

Bugfix cherry-pick branch check:

• I have checked the version labels which the pr will be auto-backported to the target branch
  • 3.4
  • 3.3
  • 3.2
  • 3.1
  • 3.0

[starrocks-cr]

The most risky bug in this code is:
Memory leak or undefined behavior due to incorrect use of Slice with StringValue.

You can modify the code like this:

Status SchemaClusterSnapshotJobsScanner::_fill_chunk(ChunkPtr* chunk) {
    auto& slot_id_map = (*chunk)->get_slot_id_to_index_map();
    const TClusterSnapshotJobsItem& info = _result.items[_index];
    DatumArray datum_array{
            Slice(info.snapshot_name.data(), info.snapshot_name.size()), 
            info.job_id, 
            info.created_time, 
            info.finished_time,
            Slice(info.state.data(), info.state.size()), 
            Slice(info.detail_info.data(), info.detail_info.size()), 
            Slice(info.error_message.data(), info.error_message.size()),
    };
    for (const auto& [slot_id, index] : slot_id_map) {
        Column* column = (*chunk)->get_column_by_slot_id(slot_id).get();
        column->append_datum(datum_array[slot_id - 1]);
    }
    _index++;
    return {};
}

In the original code, creating a Slice from info.snapshot_name, info.state, etc. directly assumes these values have valid data and size methods or properties, which may not be true or safe, especially if they have not been previously initialized or allocated correctly. Adjusting it as shown explicitly constructs the Slice with known data pointers and sizes.

[starrocks-cr]

The most risky bug in this code is:
TSchemaTableType.SCH_CLUSTER_SNAPSHOTS should match the context and might be incorrect if not properly defined elsewhere.

You can modify the code like this:

public class ClusterSnapshotsTable {
    public static final String NAME = "cluster_snapshots";

    public static SystemTable create() {
        return new SystemTable(SystemId.CLUSTER_SNAPSHOTS_ID,
                NAME,
                Table.TableType.SCHEMA,
                builder()
                        .column("SNAPSHOT_NAME", ScalarType.createVarchar(NAME_CHAR_LEN))
                        .column("SNAPSHOT_TYPE", ScalarType.createVarchar(NAME_CHAR_LEN))
                        .column("CREATE_TIME", ScalarType.createType(PrimitiveType.BIGINT))
                        .column("FINISHED_TIME", ScalarType.createType(PrimitiveType.BIGINT))
                        .column("FE_JOURNAL_ID", ScalarType.createType(PrimitiveType.BIGINT))
                        .column("STARMGR_JOURNAL_ID", ScalarType.createType(PrimitiveType.BIGINT))
                        .column("PROPERTIES", ScalarType.createVarchar(NAME_CHAR_LEN))
                        .column("STORAGE_VOLUME", ScalarType.createVarchar(NAME_CHAR_LEN))
                        .column("STORAGE_PATH", ScalarType.createVarchar(NAME_CHAR_LEN))
                        .build(), TSchemaTableType.SCH_CLUSTER_SNAPSHOTS // Ensure this value is valid for your use case.
        );
    }
}

Ensure TSchemaTableType.SCH_CLUSTER_SNAPSHOTS is accurately defined in the context of your application, as it may represent a generic or outdated placeholder that doesn't match your schema expectations.

[starrocks-cr]

The most risky bug in this code is:
A potential buffer overflow or incorrect memory size calculation for varchar-based fields using sizeof(StringValue) instead of a proper max length.

You can modify the code like this:

SchemaScanner::ColumnDesc SchemaClusterSnapshotsScanner::_s_columns[] = {
        {"snapshot_name", TypeDescriptor::create_varchar_type(MAX_SNAPSHOT_NAME_LENGTH), MAX_SNAPSHOT_NAME_LENGTH, true},
        {"snapshot_type", TypeDescriptor::create_varchar_type(MAX_SNAPSHOT_TYPE_LENGTH), MAX_SNAPSHOT_TYPE_LENGTH, true},
        {"created_time", TypeDescriptor::from_logical_type(TYPE_BIGINT), sizeof(int64_t), true},
        {"finished_time", TypeDescriptor::from_logical_type(TYPE_BIGINT), sizeof(int64_t), true},
        {"fe_jouranl_id", TypeDescriptor::from_logical_type(TYPE_BIGINT), sizeof(int64_t), true},
        {"starmgr_jouranl_id", TypeDescriptor::from_logical_type(TYPE_BIGINT), sizeof(int64_t), true},
        {"properties", TypeDescriptor::create_varchar_type(MAX_PROPERTIES_LENGTH), MAX_PROPERTIES_LENGTH, true},
        {"storage_volume", TypeDescriptor::create_varchar_type(MAX_STORAGE_VOLUME_LENGTH), MAX_STORAGE_VOLUME_LENGTH, true},
        {"storage_path", TypeDescriptor::create_varchar_type(MAX_STORAGE_PATH_LENGTH), MAX_STORAGE_PATH_LENGTH, true},
};

// Define appropriate constants for maximum lengths
const int MAX_SNAPSHOT_NAME_LENGTH = 256;
const int MAX_SNAPSHOT_TYPE_LENGTH = 256;
const int MAX_PROPERTIES_LENGTH = 1024;
const int MAX_STORAGE_VOLUME_LENGTH = 256;
const int MAX_STORAGE_PATH_LENGTH = 1024;

Explanation: The original code uses sizeof(StringValue) to define the varchar type size, which is wrong because sizeof(StringValue) returns the size of the pointer structure but does not allocate sufficient space for the actual content. This can lead to potential overflows or incorrect behavior. Proper constants should be defined and used to represent the maximum allowed sizes for each varchar field.

[sonarqubecloud]

Quality Gate passed

Issues
6 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

[Java-Extensions Incremental Coverage Report]

✅ pass : 0 / 0 (0%)

[github-actions]

[FE Incremental Coverage Report]

✅ pass : 24 / 28 (85.71%)

file detail

	path	covered_line	new_line	coverage	not_covered_line_detail
🔵	com/starrocks/service/FrontendServiceImpl.java	0	2	00.00%	[3180, 3185]
🔵	com/starrocks/catalog/system/information/ClusterSnapshotJobsTable.java	10	11	90.91%	[26]
🔵	com/starrocks/catalog/system/information/ClusterSnapshotsTable.java	12	13	92.31%	[26]
🔵	com/starrocks/catalog/system/information/InfoSchemaDb.java	2	2	100.00%	[]

[github-actions]

[BE Incremental Coverage Report]

❌ fail : 44 / 76 (57.89%)

file detail

	path	covered_line	new_line	coverage	not_covered_line_detail
🔵	be/src/exec/schema_scanner/schema_cluster_snapshots_scanner.cpp	17	33	51.52%	[53, 54, 55, 56, 57, 59, 61, 62, 63, 64, 65, 67, 68, 69, 79, 80]
🔵	be/src/exec/schema_scanner/schema_cluster_snapshot_jobs_scanner.cpp	17	33	51.52%	[51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 63, 64, 65, 75, 76]
🔵	be/src/exec/schema_scanner.cpp	4	4	100.00%	[]
🔵	be/src/exec/schema_scanner/schema_helper.cpp	6	6	100.00%	[]

[srlch]

https://github.com/Mergifyio backport branch-3.4

[mergify]

backport branch-3.4

✅ Backports have been created

• #54637 [Feature] Support Cluster Snapshot Backup: support system table for cluster snapshot backup (part2) (backport #54508) has been created for branch branch-3.4 but encountered conflicts