test: give the redis counter poll five seconds instead of one

[nic-6443]

Description

t/lib/test_redis.lua's wait_counters_above() gave up after about one second, and one second is not always enough for the counter it waits on to show up. This bounds the wait by a five second deadline instead.

Some context on why the wait exists at all, since that is where the flakiness comes from. ai-rate-limiting commits token usage in its log phase, which APISIX runs from log_by_lua_block — after the response has already gone out to the client. Cosockets are not available there, so limit-count-redis's log_phase_incoming() defers the actual write with ngx.timer.at(0, ...). That means when the test client holds request N's response, the counter for N is still unwritten: the log phase has to run, the zero-delay timer has to be picked up by the event loop, and the redis roundtrip has to complete. Fire request N+1 immediately and its access phase reads a budget that still looks unspent — which is the off-by-one-request symptom these tests used to show, wrong status codes and X-AI-RateLimit-Remaining values lagging by one request. wait_counters_above() bridges that gap: snapshot with sum_counters() before the request, then poll until the total grows.

The flaky part is the ceiling on that poll, not the logic. 100 iterations of ngx.sleep(0.01) is about one second of wall clock, and that second has to cover all three hops above plus the poller's own KEYS + GET against the same redis. On a loaded runner — parallel jobs sharing one redis container, a worker that doesn't get scheduled promptly — the write is still in flight when the poll runs out, so the helper returns an error and the caller's assert fails even though the counter lands a moment later. Nothing about it is deterministic, which is why it turns up on PRs that touch nothing in this area.

I bumped the ceiling to five seconds, but as a wall-clock deadline rather than a bigger iteration count. An iteration count bounds only the sleeps: each pass also does a full sum_counters() round trip, so the real ceiling stretches with redis latency — precisely the condition the wait exists to absorb. At 100ms per poll, 500 iterations would run for the better part of a minute while the comment above it claimed five seconds. A deadline says what it means.

The loop still returns as soon as the counter moves, so a healthy run costs exactly what it did before.

The only caller today is t/plugin/ai-rate-limiting.t TEST 37.

Checklist

• I have explained the need for this PR and the problem it solves
• I have explained the changes or the new features added to this PR
• I have added tests corresponding to this change
• I have updated the documentation to reflect this change
• I have verified that this change is backward compatible (If not, please discuss on the APISIX mailing list first)

This is a test-only change to a test helper, so no new tests or documentation.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[membphis]

LGTM