increase thresholds for async ppl timings

[Swiddis]

Description

attempt to fix unit test flakes on the windows platform that I've been seeing in #5888 and #5878.

Related Issues

N/A

Check List

• New functionality includes testing.
• New functionality has been documented.
• New functionality has javadoc added.
• New functionality has a user manual doc added.
• New PPL command checklist all confirmed.
• API changes companion pull request created.
• Commits are signed per the DCO using --signoff or -s.
• Public documentation issue/PR created.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🧪 No relevant tests

🔒 No security concerns identified

✅ No TODO sections

🔀 No multiple PR themes

⚡ Recommended focus areas for review Logic Change RUNNING_MIN_PROGRESS changed from 10 to 1. This significantly lowers the minimum progress threshold, which may cause tests to pass prematurely before meaningful work is done. If the original value of 10 was chosen to ensure a certain amount of processing occurred before validation, reducing it to 1 could mask issues where queries complete too quickly or fail to process expected data volumes. private static final long RUNNING_MIN_PROGRESS = 1;

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
General	Increase minimum progress threshold Setting RUNNING_MIN_PROGRESS to 1 may cause flaky tests as it allows queries to be considered "running" after processing just a single document. This extremely low threshold could lead to race conditions where the test passes the running check before meaningful work has occurred. integ-test/src/test/java/org/opensearch/sql/ppl/AsyncPPLTestHelpers.java [54] -private static final long RUNNING_MIN_PROGRESS = 1; +private static final long RUNNING_MIN_PROGRESS = 5; Suggestion importance[1-10]: 5 __ Why: The suggestion raises a valid concern about potential race conditions with RUNNING_MIN_PROGRESS = 1, but the score is moderate because: (1) the change from 10 to 1 was intentional in the PR, suggesting the developer may have reasons for this lower threshold, and (2) without test failure evidence or understanding the full context of how this constant is used, the suggestion is speculative about flakiness.	Low

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 63.86%. Comparing base (44b1a76) to head (a47616c).
⚠️ Report is 6 commits behind head on main.

❌ Your project check has failed because the head coverage (63.86%) is below the target coverage (99.00%). You can increase the head coverage or adjust the target coverage.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #5889      +/-   ##
============================================
- Coverage     63.87%   63.86%   -0.02%     
- Complexity     9091     9093       +2     
============================================
  Files           962      962              
  Lines         41033    41048      +15     
  Branches       4668     4669       +1     
============================================
+ Hits          26211    26214       +3     
- Misses        13944    13956      +12     
  Partials        878      878              

Flag	Coverage Δ
sql-engine	63.86% <ø> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 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.