[AMORO-4236] Splitting the “Optimizing” tab into the “Optimizing” tab,“Cleanup” tab and “Profiling” tab

[zhangwl9]

Why are the changes needed?

Close #4236.

Brief change log

Introduces Maintenance tab in the table details page to separate maintenance processes (cleanup operations) from optimizing processes.

Key changes:

• Backend: Add processCategory parameter to getOptimizingProcessesInfo API to filter by OPTIMIZING or MAINTENANCE category
• Backend: Add new REST endpoint /maintenance-types to fetch maintenance-specific process types
• Backend: Update MixedAndIcebergTableDescriptor to support category-based filtering with proper type separation
• Frontend: Create reusable Maintenance.vue component that wraps Optimizing.vue with maintenance-specific configuration
• Frontend: Add processCategory and cancelModalTitleKey props to Optimizing.vue for flexible reuse
• Frontend: Register Maintenance tab in table details page alongside Optimizing tab

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)

[zhoujinsong]

Overall: Good design direction, but suggest refining the category taxonomy before merging.

The idea of separating table processes into different tabs is great. However, I think MAINTENANCE is too broad a category and we should consider a more precise taxonomy that better aligns with the nature of these operations.

Suggested Classification

Instead of a binary OPTIMIZING / MAINTENANCE split, I'd suggest a three-way classification:

Category	Purpose	Current Operations	Future Extensions
OPTIMIZING	Performance optimization (data reorganization)	Minor / Major / Full Compaction	Clustering, Sort Rewrite
CLEANUP	Space reclamation & lifecycle management	Expire Snapshots, Expire Data, Clean Orphan Files, Clean Dangling Delete Files	VACUUM, Remove Old Metadata
PROFILING	Information enrichment & metadata augmentation	Auto Create Tags	Collect Statistics, Build Index

Additionally, Sync Hive Tables is more of an internal implementation detail and probably should not be exposed to users in any tab.

Rationale

• "Maintenance" is too vague — compaction could also be considered "maintenance" in a broad sense.
• The operations currently under MAINTENANCE actually serve two distinct purposes: space reclamation (Expire/Clean) vs. metadata enrichment (Auto Create Tags). As we add more operations (e.g., statistics collection), this distinction will become more important.
• This three-way split aligns with industry conventions: Delta Lake has OPTIMIZE / VACUUM, Iceberg docs separate "rewrite" from "expire/remove".

Suggested Approach

For the backend API, I'd recommend defining three processCategory values upfront: OPTIMIZING, CLEANUP, PROFILING. This makes the API future-proof.

For the frontend, there are two pragmatic options:

1. Three tabs (Optimizing / Cleanup / Profiling) — cleanest separation
2. Two tabs for now (Optimizing / Cleanup) — merge Profiling into Cleanup since there's currently only one profiling operation (Auto Create Tags), and split it out later when more profiling operations are added

Either way, the endpoint could be generalized from /maintenance-types to something like /process-types?category=CLEANUP for better extensibility.

What do you think?

[zhangwl9]

Overall: Good design direction, but suggest refining the category taxonomy before merging.

The idea of separating table processes into different tabs is great. However, I think MAINTENANCE is too broad a category and we should consider a more precise taxonomy that better aligns with the nature of these operations.

Suggested Classification

Instead of a binary OPTIMIZING / MAINTENANCE split, I'd suggest a three-way classification:

Category Purpose Current Operations Future Extensions
OPTIMIZING Performance optimization (data reorganization) Minor / Major / Full Compaction Clustering, Sort Rewrite
CLEANUP Space reclamation & lifecycle management Expire Snapshots, Expire Data, Clean Orphan Files, Clean Dangling Delete Files VACUUM, Remove Old Metadata
PROFILING Information enrichment & metadata augmentation Auto Create Tags Collect Statistics, Build Index
Additionally, Sync Hive Tables is more of an internal implementation detail and probably should not be exposed to users in any tab.

Rationale

• "Maintenance" is too vague — compaction could also be considered "maintenance" in a broad sense.
• The operations currently under MAINTENANCE actually serve two distinct purposes: space reclamation (Expire/Clean) vs. metadata enrichment (Auto Create Tags). As we add more operations (e.g., statistics collection), this distinction will become more important.
• This three-way split aligns with industry conventions: Delta Lake has OPTIMIZE / VACUUM, Iceberg docs separate "rewrite" from "expire/remove".

Suggested Approach

For the backend API, I'd recommend defining three processCategory values upfront: OPTIMIZING, CLEANUP, PROFILING. This makes the API future-proof.

For the frontend, there are two pragmatic options:

1. Three tabs (Optimizing / Cleanup / Profiling) — cleanest separation
2. Two tabs for now (Optimizing / Cleanup) — merge Profiling into Cleanup since there's currently only one profiling operation (Auto Create Tags), and split it out later when more profiling operations are added

Either way, the endpoint could be generalized from /maintenance-types to something like /process-types?category=CLEANUP for better extensibility.

What do you think?

Your feedback is very helpful. Thank you very much. The new commit has been fixed and the latest screenshots have also been updated above. The changes are as follows：
Changes:

• Add ProcessCategory enum with OPTIMIZING, CLEANUP, PROFILING
• Replace getTableMaintenanceTypes() with getTableProcessTypes(category)
• Remove excludeTypes parameter from TableProcessMapper.listProcessMeta()
• Merge /optimizing-types and /maintenance-types into /process-types endpoint
• Split Maintenance.vue into Cleanup.vue and Profiling.vue
• Update HudiTableDescriptor and PaimonTableDescriptor
• Fix TestIcebergServerTableDescriptor to pass processCategory parameter

BREAKING CHANGE:

• Removed /optimizing-types and /maintenance-types REST
  endpoints.
• Use /process-types?processCategory=OPTIMIZING|CLEANUP|PROFILING.
• SPI method getTableMaintenanceTypes() replaced by getTableProcessTypes().