[test](regression) Move memory-intensive external cases to P2

[suxiaogang223]

What problem does this PR solve?

Issue Number: None

Related PR: None

Problem Summary:

The P0 external regression pipeline currently starts several memory-intensive Docker services for relatively low-priority compatibility coverage. This PR reduces the P0 resource footprint by moving the following service-specific cases and expected results to P2:

• DB2
• SQL Server / MSSQL, including the SQL Server Trino connector and row-count coverage
• OceanBase
• Elasticsearch 5/6/7/8, including ES MTMV coverage

The SQL Server row-count checks are split from the mixed P0 JDBC suite so the existing MySQL, PostgreSQL, and Oracle P0 coverage remains unchanged. The ES MTMV database reference is updated to match its new P2 directory.

Kerberos was evaluated separately but remains required in P0 for safety. The earlier Kerberos move has been fully reverted, so the cumulative diff of this PR contains no Kerberos file changes.

This PR only changes regression-suite grouping and paths. It does not change Docker service configuration, runtime behavior, query behavior, or expected test results.

Release note

None

Check List (For Author)

• Test:
  • Regression test
  • Unit Test
  • Manual test
  • No need to test: this is a suite-grouping and path-only change. Verified P0/P2 labels, dependency references, expected-result paths, source equivalence, mergeability with current master, absence of Kerberos files from the cumulative PR diff, and git diff --check.
• Behavior changed:
  • Yes. DB2, SQL Server, OceanBase, and all Elasticsearch regression cases run in P2 instead of P0. Kerberos continues to run in P0.
• Does this need documentation:
  • No

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

[suxiaogang223]

run buildall

[suxiaogang223]

/review

[github-actions]

Codex automated review failed and did not complete.

Error: You've hit your usage limit. Visit https://chatgpt.com/codex/settings/usage to purchase more credits or try again at 10:57 AM.
Workflow run: https://github.com/apache/doris/actions/runs/29085116070

Please inspect the workflow logs and rerun the review after the underlying issue is resolved.

[Gabriel39]

/review

[github-actions]

Found one blocking issue: the moved external-service suites are labelled p2,external, but the checked-in external regression stage excludes p2 and there is no wired P2 external trigger/config in the current TeamCity/GitHub trigger mapping.

Critical checkpoint conclusions:

• Goal/test proof: the PR intends to preserve DB2, SQL Server, OceanBase, Elasticsearch, and Kerberos coverage at P2 frequency, but the current pipeline evidence does not prove those cases will still run.
• Scope: the suite/data moves are otherwise focused; expected-result files are 100% renames and the SQL Server row-count split preserves the old assertions.
• Parallel paths: the moved ES/JDBC/Kerberos/MTMV filenames are absent from the old P0 locations, and test_es_mtmv updates its derived MTMV database name consistently with the new mtmv_p2 path.
• Concurrency, lifecycle, transaction/persistence, FE-BE protocol, observability, and data-write runtime behavior: not applicable beyond test execution because this is a regression-suite grouping change.
• Tests/results: static review only. This checkout is shallow and .worktree_initialized/thirdparty setup is absent, so I did not run the external regression suites. A scoped whitespace check reports inherited .out/renamed-file whitespace, not a new semantic result change.
• User focus: no additional user-provided focus points.

Subagent conclusions: tests-session-config proposed TSC-1, accepted as the inline comment below. optimizer-rewrite proposed OPT-1, dismissed with evidence because it concerns LeadingHint.java, which is not in this PR diff. Convergence round 1 ended with both live subagents returning NO_NEW_VALUABLE_FINDINGS for the final ledger/comment set.

[github-actions]

PR approved by at least one committer and no changes requested.

[suxiaogang223]

run buildall

is ok

[suxiaogang223]

/review

[github-actions]

Automated review completed for PR 65459 at head 1a0e768c113865adcaa9e65eb975493e5d9f8b80.

I found no new non-duplicative inline issues to submit. The main correctness concern is already covered by the existing inline thread on regression-test/suites/external_table_p2/jdbc/test_sqlserver_jdbc_catalog.groovy:18: the moved p2,external suites are filtered out by the checked-in external regression config (testGroups = "external", excludeGroups = "p1,p2"), and I found no wired p2 or external_p2 TeamCity/comment trigger with the required external service configuration.

Checkpoint conclusions:

• Goal/test proof: this PR demotes several external ES/JDBC/MTMV suites from P0 to P2 and splits SQL Server row-count coverage into its own suite. The file moves and .out pairings are internally consistent, but the P2 external execution path concern remains as already commented.
• Scope: the change is narrow test relocation plus one test split.
• Concurrency/lifecycle/transactions/persistence/FE-BE protocol: not applicable; no production code paths are changed.
• Config/parallel paths: no new config items are added, but the parallel CI selection path for external P2 is the known gap already raised in the existing inline thread.
• Test result files: moved result files have matching new suite paths; assertion-only/doc/http-open-api/row-count suites do not require .out files.
• SQL Server row-count split: no distinct setup or correctness issue found; the standalone suite preserves the old SQL Server setup, polling, expected counts, and cleanup.
• User focus: no additional user-provided review focus was present.

I did not run builds or tests because the review prompt explicitly says this environment is only for review operations and not to attempt builds.