Save the last completion time for each cleanup operation performed on each optimization table.

[zhangwl9]

Why are the changes needed?

Close #3781.

Brief change log

To optimize table cleanup operations (Dangling-Delete_file cleanup, data expiration, orphan_file cleanup,snapshotsFile cleanup), the last cleanup time is saved. This ensures that after an AMS service restart, if a cleanup operation was completed just before the restart, the next cleanup operation will only be performed after exceeding the respective execution interval.
The execution flow is as follows:

• During the initialization of the ams service, retrieve the last execution time for each cleanup operation of every table to be optimized from the table_runtime_state table.

• Check whether the time interval since the last cleanup exceeds the cleanup operation execution interval.

• For optimization tables exceeding the execution interval, execute the cleanup operation.

• Otherwise, schedule for the next round of execution.

• Since each table's cleanup operation takes varying durations, after a table's cleanup completes, update the cleanup completion time in the table_runtime_state table.

How was this patch tested?

• Add some test cases that check the changes thoroughly including negative and positive cases if possible

• Add screenshots for manual tests if appropriate

• Run test locally before making a pull request

Documentation

• Does this pull request introduce a new feature? (yes / no)
• If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

[codecov-commenter]

Codecov Report

❌ Patch coverage is 60.78431% with 40 lines in your changes missing coverage. Please review.
✅ Project coverage is 28.93%. Comparing base (fd44c44) to head (2aba806).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
...amoro/server/scheduler/PeriodicTableScheduler.java	40.81%	28 Missing and 1 partial ⚠️
...apache/amoro/server/table/DefaultTableRuntime.java	88.46%	1 Missing and 2 partials ⚠️
...er/inline/DanglingDeleteFilesCleaningExecutor.java	0.00%	2 Missing ⚠️
.../server/scheduler/inline/DataExpiringExecutor.java	0.00%	2 Missing ⚠️
.../scheduler/inline/OrphanFilesCleaningExecutor.java	0.00%	2 Missing ⚠️
...er/scheduler/inline/SnapshotsExpiringExecutor.java	0.00%	2 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #3802      +/-   ##
============================================
- Coverage     29.45%   28.93%   -0.53%     
+ Complexity     4236     3870     -366     
============================================
  Files           670      631      -39     
  Lines         55245    50743    -4502     
  Branches       6983     6480     -503     
============================================
- Hits          16273    14682    -1591     
+ Misses        37778    35011    -2767     
+ Partials       1194     1050     -144     

Flag	Coverage Δ
core	28.93% <60.78%> (+0.11%)	⬆️
trino	?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[zhangwl9]

I have completed the logic modification to save cleanup times to the table_runtime_state table. Could you please review the code at your convenience? Thank you very much. @czy006 @baiyangtx