[Enhancement] Collect ClusterSnapshotInfo via cluster snapshot checkpoint

[srlch]

What I'm doing:

In this pr #59845, we introduce ClusterSnapshotInfo. This info is used to save some snapshot info for a single cluster snapshot. This pr introduce a mechanism that collect such information during cluster snapshot checkpoint.

What I'm doing:

Fixes #issue

What type of PR is this:

• [ ] BugFix
• [ ] Feature
• [x] Enhancement
• [ ] Refactor
• [ ] UT
• [ ] Doc
• [ ] Tool

Does this PR entail a change in behavior?

• [ ] Yes, this PR will result in a change in behavior.
• [x] 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:

• [x] 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:

• [x] I have checked the version labels which the pr will be auto-backported to the target branch
  • [ ] 3.5
  • [ ] 3.4
  • [ ] 3.3

[srlch]

could you explain the mechanism you designed to collect SnapshotInfo during checkpoint? I feel a little confused from reading the code.

When cluster snapshot begin, the snapshot scheduler will try to get checkpoint ids and send it to checkpoint controller to trigger a new round of checkpoint. After finishing, we will get a new image file corresponding to the checkpoint ids which is what we needed in cluster snapshot. Cluster snapshot info can be considered as part of the snapshoted image. It contains the necessary info to tell us what we actually snapshoted. So if we want to get it, we can build this info from checkpoint worker just after the image file has been flushed into disk.

[sonarqubecloud[bot]]

Quality Gate failed

Failed conditions
B Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[github-actions[bot]]

[Java-Extensions Incremental Coverage Report]

:white_check_mark: pass : 0 / 0 (0%)

[github-actions[bot]]

[FE Incremental Coverage Report]

:white_check_mark: pass : 44 / 53 (83.02%)

file detail

	path	covered_line	new_line	coverage	not_covered_line_detail
:large_blue_circle:	com/starrocks/service/FrontendServiceImpl.java	0	2	00.00%	[2990, 3021]
:large_blue_circle:	com/starrocks/lake/snapshot/ClusterSnapshotCheckpointScheduler.java	1	3	33.33%	[118, 127]
:large_blue_circle:	com/starrocks/journal/GlobalStateCheckpointWorker.java	3	5	60.00%	[56, 57]
:large_blue_circle:	com/starrocks/leader/CheckpointController.java	19	21	90.48%	[225, 475]
:large_blue_circle:	com/starrocks/journal/CheckpointWorker.java	11	12	91.67%	[104]
:large_blue_circle:	com/starrocks/lake/snapshot/ClusterSnapshotJob.java	8	8	100.00%	[]
:large_blue_circle:	com/starrocks/lake/snapshot/ClusterSnapshot.java	2	2	100.00%	[]

[github-actions[bot]]

[BE Incremental Coverage Report]

:white_check_mark: pass : 0 / 0 (0%)