[Amoro-3762][Subtask] Change TableService to SPI mode to support expansion of other implementation methods.

[wardlican]

Why are the changes needed?

Close #3762.

Brief change log

Solution Overview

Added a new SPI factory interface, TableServiceProvider (based on ServiceLoader).
Provides a default implementation, DefaultTableServiceProvider, and registers it in META-INF/services.
Added a new configuration option, TABLE_SERVICE_IMPL (string), with two supported syntaxes:
-- Specify the provider name (e.g., default)
-- Specify the implementation class name (e.g., org.apache.amoro.server.table.DefaultTableService)
Creates a TableService in the AmoroServiceContainer using a configuration-based loader method.
Retains the existing default behavior: Falling back to DefaultTableService when not configured.

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)

[baiyangtx]

Why use the SPI approach to give TableService different implementations instead of directly adding multi-node scaling to the current TableService? Whether to deploy in multi-node mode should be controlled by a simple configuration flag; it shouldn’t require a completely separate TableService implementation.

[baiyangtx]

Who will call those methods?

[wardlican]

This method is mentioned in the interface for compatibility with the original test cases in SPI mode, and secondly, this method also needs to be implemented in master-slave mode. @baiyangtx @zhoujinsong

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 21.71%. Comparing base (e3c16af) to head (e4e5f3b).
⚠️ Report is 5 commits behind head on master.

❗ There is a different number of reports uploaded between BASE (e3c16af) and HEAD (e4e5f3b). Click for more details.

HEAD has 3 uploads less than BASE

Flag	BASE (e3c16af)	HEAD (e4e5f3b)
core	3	0

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #3764      +/-   ##
============================================
- Coverage     28.53%   21.71%   -6.82%     
+ Complexity     3759     2388    -1371     
============================================
  Files           617      439     -178     
  Lines         50056    40611    -9445     
  Branches       6482     5743     -739     
============================================
- Hits          14283     8819    -5464     
+ Misses        34760    31047    -3713     
+ Partials       1013      745     -268     

Flag	Coverage Δ
core	?
trino	21.71% <ø> (?)

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.

[wardlican]

t TableService? Whether to deploy in multi-node mode should be controlled by a simple configuration flag; it shouldn’t require a completely separate TableService implementation.

To distinguish between the master-slave mode and the master-slave mode, the newly added master-slave mode should not affect the original logic. The master-slave mode will make more logical changes in TableServcie.

[baiyangtx]

To distinguish between the master-slave mode and the master-slave mode, the newly added master-slave mode should not affect the original logic. The master-slave mode will make more logical changes in TableServcie.

Will the two implementations be merged in the future?
In the long run, the horizontally-scalable version is likely to become the default. If we do expect a single unified implementation eventually, we could simply switch between the two code paths with a config flag today instead of introducing a full SPI framework. After all, TableService is not intended to be opened up for third-party plug-ins down the road.

WDYT @zhoujinsong @Aireed

[wardlican]

To distinguish between the master-slave mode and the master-slave mode, the newly added master-slave mode should not affect the original logic. The master-slave mode will make more logical changes in TableServcie.

Will the two implementations be merged in the future? In the long run, the horizontally-scalable version is likely to become the default. If we do expect a single unified implementation eventually, we could simply switch between the two code paths with a config flag today instead of introducing a full SPI framework. After all, TableService is not intended to be opened up for third-party plug-ins down the road.

WDYT @zhoujinsong @Aireed

Yes, the design here needs to decide whether to implement compatible logic through configuration in DefaultTableService.

[zhoujinsong]

I'm also hesitant about whether it's necessary to add SPI extension. Perhaps it would be better if the existing implementation simply supports horizontal scaling, as the master-slave architecture will eventually be replaced by a multiple-master architecture.

[wardlican]

I'm also hesitant about whether it's necessary to add SPI extension. Perhaps it would be better if the existing implementation simply supports horizontal scaling, as the master-slave architecture will eventually be replaced by a multiple-master architecture.

OK, here i will change it to implement the master-slave mode logic in DefaultTableService through configuration.