[AMORO-4099] Add table-summary metric collection option for non-optimizing tables

[j1wonpark]

Why are the changes needed?

Currently, table_summary metrics (total files, file sizes, health score, etc.) are only collected when self-optimizing.enabled=true. The metric update path (setTableSummary()) is gated behind the optimizingConfig.isEnabled() check in TableRuntimeRefreshExecutor.tryEvaluatingPendingInput(), so tables with self-optimizing disabled always show 0 or N/A in Grafana dashboards.

This PR decouples metric collection from self-optimizing execution by introducing a new table property table-summary.enabled.

Close #4099.

Brief change log

• Add table-summary.enabled table property constant in TableProperties (default: false)
• Add tableSummaryEnabled field to OptimizingConfig with getter/setter
• Parse the new property in TableConfigurations.parseOptimizingConfig()
• Add else if branch in TableRuntimeRefreshExecutor.tryEvaluatingPendingInput() to collect summary metrics when optimizing is disabled but table-summary is enabled
• Skip adaptive interval adjustment for table-summary-only mode to maintain fixed collection interval
• Add TestTableSummaryWithoutOptimizing test class with 7 test cases

How was this patch tested?

• Add some test cases that check the changes thoroughly including negative and positive cases if possible
  • testSummaryCollectedWhenOptimizingDisabledAndSummaryEnabled: verifies metrics are updated when optimizing is off but summary is enabled
  • testSummaryNotCollectedWhenOptimizingDisabledWithDefault: verifies metrics remain at initial values when only optimizing is disabled (table-summary defaults to false)
  • testSummaryCollectedRepeatedlyWithoutNewSnapshots: verifies metrics are collected on repeated refreshes when unoptimized data exists
  • testSummaryUpdatedAfterNewSnapshotInSummaryOnlyMode: verifies metrics reflect new data appended in summary-only mode
  • testPropertyKeyNotFilteredWhenOptimizingDisabled: verifies table-summary.enabled is parsed independently from self-optimizing.enabled
  • testReEnableOptimizingAfterSummaryOnlyMode: verifies normal optimizing path works after re-enabling
  • testSummaryCollectedWithOptimizingEnabled: verifies summary is always collected in the optimizing-enabled path
• 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
• If yes, how is the feature documented? JavaDocs

[codecov-commenter]

Codecov Report

❌ Patch coverage is 50.00000% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 28.86%. Comparing base (fda105e) to head (88f649c).
⚠️ Report is 3 commits behind head on master.

Files with missing lines	Patch %	Lines
...java/org/apache/amoro/config/OptimizingConfig.java	0.00%	5 Missing ⚠️
.../scheduler/inline/TableRuntimeRefreshExecutor.java	80.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #4101      +/-   ##
============================================
+ Coverage     22.39%   28.86%   +6.46%     
- Complexity     2552     3951    +1399     
============================================
  Files           458      654     +196     
  Lines         42116    52175   +10059     
  Branches       5917     6637     +720     
============================================
+ Hits           9433    15061    +5628     
- Misses        31871    36013    +4142     
- Partials        812     1101     +289     

Flag	Coverage Δ
core	28.86% <50.00%> (?)
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.

[github-actions]

This pull request has been marked as stale due to 30 days of inactivity. It will be closed in 1 week if no further activity occurs. If you think that’s incorrect or this pull request requires a review, please simply write any comment. If closed, you can revive the PR at any time and @mention a reviewer or discuss it on the dev@amoro.apache.org list. Thank you for your contributions.