[fix](test) Make test_analyze_long_string Case 5 stable against sample rows randomness

[yujun777]

Problem

test_analyze_long_string Case 5 (and potentially Case 3) can flake because
after inserting data, the BE may not have reported the row count to FE yet.

When OlapAnalysisTask.doExecute() runs with info.rowCount == 0 and
tableSample != null, it returns early without executing any SQL — the
column finishes with FINISHED state but an empty message, so the expected
skip reason from the assert_true long-string guard is never produced:

expected skip reason visible for col big_str, got msg=
==> expected: <true> but was: <false>

The audit log confirms that no sampling SQL was issued for big_str in
the failing run — the task was short-circuited entirely.

Fix

1. Suite.groovy: Add waitRowCountReady(db, table, expectedRowCount)
   that polls SHOW DATA FROM db.table via sql_return_maparray until
   the BE-reported row count reaches the expected value.

2. test_analyze_long_string.groovy: Call waitRowCountReady after
   inserts for both sample analyze cases:

   • Case 3 (sample percent 100)
   • Case 5 (sample rows 3, DUJ1 template)

3. Case 5 data uses repeat('z', 2048) for all rows — a secondary defense
   against sample randomness missing the long row even when row count is
   properly reported.

[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?

[yujun777]

run buildall

[github-actions]

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

[github-actions]

PR approved by anyone and no changes requested.

[yujun777]

run nonConcurrent

[morrySnow]

/review

[zclllyybb]

skip buildall

[github-actions]

Reviewed PR #64408 against the repository code-review skill and existing review context. I found no blocking issues.

Critical checkpoint conclusions:

• Goal/test proof: The PR targets flakiness in Case 5 of test_analyze_long_string by ensuring every possible sample rows 3 DUJ1 sample contains a big_str value longer than statistics_max_string_column_length. This matches the intended assertion path, and the PR's nonConcurrent regression check is passing.
• Scope/focus: The change is limited to test fixture data in one regression suite and is appropriately small.
• Concurrency/lifecycle/locks: No new concurrent code, lifecycle management, or locking is introduced.
• Config/compatibility/protocol/storage: No config item, protocol, storage format, or compatibility behavior is changed.
• Parallel paths: Case 5 specifically covers forced DUJ1 sampling; the existing suite still covers full, sample percent 100, partition-path exception, disabled limit, and sync analyze behavior.
• Conditional checks/error handling: No new conditional logic or error handling is added.
• Test coverage/result files: The changed test remains assertion-based like the existing suite and does not require an .out file. I did not run the suite locally; I verified the PR check output shows NonConcurrent Regression passing.
• Observability/performance/security: Not applicable for this test-data-only change.

User focus: no additional user-provided review focus was present.

[yujun777]

need modify

[yujun777]

run buildall

[yujun777]

run buildall

[zclllyybb]

/review

[github-actions]

No blocking issues found in this PR.

Checkpoint conclusions:

• Goal and proof: The change targets the sampled-analyze race where AnalysisInfo.rowCount is captured before BE row-count reporting catches up. The new waits are placed before the Case 3 and Case 5 ANALYZE statements, which is before AnalysisManager.buildAnalysisJobInfo() snapshots row count, so they address the intended failure mode.
• Scope: The patch is small and focused: one regression-framework helper plus two uses in test_analyze_long_string.
• Concurrency/lifecycle: The only relevant concurrency is asynchronous BE row-count reporting versus FE analyze-job creation. The test now waits for the BE-reported count before creating the analyze job. No production locks, static lifecycle, or new persistent state are introduced.
• Configuration/compatibility: No new config, storage format, RPC/thrift, or rolling-upgrade compatibility surface.
• Parallel paths: Both sampled paths covered by this test are handled: sample percent 100 and forced DUJ1 sample rows. Full analyze and sync analyze paths do not depend on this sampled-empty shortcut.
• Conditional logic: The wait condition is concrete (SHOW DATA row count reaches the expected inserted rows) and scoped to regression stabilization.
• Test coverage/results: The strengthened regression test covers the flaky path directly; no .out change is needed because this suite uses assertions. I did not rerun tests locally, but PR checks show NonConcurrent Regression, P0 Regression, External Regression, compile, formatter, and license checks passing.
• Observability/performance: The helper logs SHOW DATA while polling; the 120s/3s polling cost is limited to regression tests.
• Transaction/persistence/data correctness: No production transaction or persistence behavior changes; the test waits after committed inserts and before analyze job creation.
• FE/BE variable passing: Not applicable.
• User focus: No additional user-provided focus points were present, and I found no focus-specific issues.