Add POST /tableConfigs/tune endpoint to apply tuning and return tuned config

[rseetham]

What is this PR doing / why is it needed?

The existing POST /tableConfigs/validate endpoint validates the provided TableConfigs and returns the input as-is (modulo database name translation). However, the actual create (POST /tableConfigs) and update (PUT /tableConfigs/{tableName}) paths apply additional tuning before persisting:

• Tuner configs (e.g. realtimeAutoIndexTuner)
• Minimum replicas enforcement
• Dimension table storage quota constraints

This means callers have no way to preview what would actually be stored without performing the real operation.

This PR adds a new POST /tableConfigs/tune endpoint that validates the TableConfigs and then applies the same tuning as create/update, returning the resulting config. This lets callers preview the final tuned config before committing.

Changes

• Added POST /tableConfigs/tune endpoint in TableConfigsRestletResource
• Refactored shared parsing/validation/permission-check logic into a private parseAndValidateTableConfigs helper, used by both validate and tune endpoints
• Renamed private tuneConfig(TableConfig, Schema) helper to applyTuning to avoid name collision with the new public endpoint method
• Added forTableConfigsTune() to ControllerRequestURLBuilder
• Added testTuneConfig test in TableConfigsRestletResourceTest covering: invalid input, min replicas, dim table quota, tuner config application, and unrecognized properties passthrough

Testing Done

All existing TableConfigsRestletResourceTest tests pass. New testTuneConfig test added and passing.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 95.65217% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 63.35%. Comparing base (abdb6cb) to head (4c2987d).
⚠️ Report is 2 commits behind head on master.

Files with missing lines	Patch %	Lines
...ler/api/resources/TableConfigsRestletResource.java	95.45%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master   #18056      +/-   ##
============================================
+ Coverage     63.34%   63.35%   +0.01%     
+ Complexity     1543     1540       -3     
============================================
  Files          3200     3200              
  Lines        194222   194237      +15     
  Branches      29934    29931       -3     
============================================
+ Hits         123026   123065      +39     
+ Misses        61526    61509      -17     
+ Partials       9670     9663       -7     

Flag	Coverage Δ
custom-integration1	100.00% <ø> (ø)
integration	100.00% <ø> (ø)
integration1	100.00% <ø> (ø)
integration2	0.00% <ø> (ø)
java-11	63.30% <95.65%> (-0.01%)	⬇️
java-21	63.32% <95.65%> (+<0.01%)	⬆️
temurin	63.35% <95.65%> (+0.01%)	⬆️
unittests	63.35% <95.65%> (+0.01%)	⬆️
unittests1	55.52% <0.00%> (+<0.01%)	⬆️
unittests2	34.26% <95.65%> (+<0.01%)	⬆️

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:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[tarun11Mavani]

LGTM

[shauryachats]

Instead of a new endpoint, could we consider adding a applyTuneConfigs param to POST /tableConfigs/validate since this endpoint validates as well as applies tuner configs to the input table config - hence it is an extension of the validate endpoint.

[rseetham]

Validate also tuning configs is not obvious. The tune configs could be extended in the future for more tuning. The validate is there to make sure the tuning does not fail devise the input is invalid.