[AMORO-1951] Support parallelized planning in one optimizer group

[majin1102]

Why are the changes needed?

Close #1951 .

Brief change log

• Support parallelized planning by a parameter named as maxPlanningParallelism
• Refactor OptimizingQueue and DefaultOptimizingService
• Refactor suspending optimizer checker by using DelayedQueue for better SLA
• add two other global parameters for optimizing:

  private final long pollingTimeout; // optimizing max waiting time when polling, default 3000ms
  private final long minPlanningInterval; // min table planning interval, default 60 seconds 

• add unit tests for OptimizingQueue and DefaultOptimizingService

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)
• If yes, how is the feature documented? (under Configurations)

[codecov]

Codecov Report

Attention: 63 lines in your changes are missing coverage. Please review.

Comparison is base (365100a) 52.97% compared to head (e6efd97) 53.52%.

Files	Patch %	Lines
...ease/arctic/server/optimizing/OptimizingQueue.java	80.00%	15 Missing and 8 partials ⚠️
...etease/arctic/server/DefaultOptimizingService.java	88.32%	13 Missing and 3 partials ⚠️
...ase/arctic/server/optimizing/SchedulingPolicy.java	63.63%	7 Missing and 5 partials ⚠️
...etease/arctic/server/resource/OptimizerThread.java	66.66%	5 Missing ⚠️
...rctic/server/persistence/StatedPersistentBase.java	84.61%	4 Missing ⚠️
.../netease/arctic/server/optimizing/TaskRuntime.java	91.66%	1 Missing and 2 partials ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #2282      +/-   ##
============================================
+ Coverage     52.97%   53.52%   +0.55%     
- Complexity     4311     4359      +48     
============================================
  Files           516      517       +1     
  Lines         29805    29831      +26     
  Branches       2902     2903       +1     
============================================
+ Hits          15789    15968     +179     
+ Misses        12738    12576     -162     
- Partials       1278     1287       +9     

Flag	Coverage Δ
core	54.01% <83.76%> (+0.66%)	⬆️
trino	50.93% <ø> (-0.03%)	⬇️

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.

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

majin1102 seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[HuangFru]

I've tested it with max-planning-parallelism 1 and 5. Works fine.

[HuangFru]

There is a very important point here. In iceberg native plan logic, multi-threaded plan is used by default. And this multi-threaded thread pool is still public (including commit and other operations will also use this thread pool). So when a large table (which may have unhealthy metadata) takes up a lot of resources during planning. Even if multiple tables are allowed to plan at the same time, the plan speed of other tables will become very slow, and even the speed of commit will be greatly affected. This PR has not yet solved this problem.

[zhoujinsong]

I left some comments, please take another look.
The code style seems to be incorrect, you can follow this guide to correct it:https://github.com/NetEase/amoro/blob/master/CONTRIBUTING.md#code-formatting

[zhoujinsong]

@majin1102 I left some comments, please task a look.

[zhongqishang]

@majin1102 I left some comments, PTAL.

And I tested the following scenario and it didn't work properly:
When AMS is restarted in the optimizing running state, the execution of unfinished tasks is not resumed.

[zhoujinsong]

LGTM.

[zhongqishang]

LGTM.