fix(healthcheck): purge stale targets and release periodic lock (bump lua-resty-healthcheck-api7 to 3.2.2)

[AlinsRan]

Description

Fixes a cluster of active-health-check bugs whose root cause is in the health-check library, by bumping lua-resty-healthcheck-api7 from 3.2.1-0 to 3.2.2-0 (which carries api7/lua-resty-healthcheck#55) and adding a regression test.

apisix already marks removed targets via delayed_clear() and re-creates checkers on enable; the library was the layer failing to act on that:

• bug: After a node is deleted from the upstream, its information can still be queried from the health check interface. #13385 — a deleted node was still returned by /v1/healthcheck.
• bug: health check keeps probing stale upstream nodes after nodes update (checker cache not invalidated) #13141 — a deleted node was still actively probed.
  Both share one cause: the library advanced a module-level cleanup timestamp inside its per-checker loop, so only the first checker was purged each window. With multiple health-checked upstreams the rest kept their delayed_clear()-marked nodes forever. (doc: limited the picture size if it's small #55 elects one cleanup worker per window and purges every checker; it also decouples cleanup from the periodic lock so passive-only deployments are cleaned too.)
• bug: healthcheck not work #13235 — active health checks stayed dead after a disable→re-enable cycle, because the periodic-lock holder never released the lock when it went idle, starving the worker that still owned active checkers. (doc: limited the picture size if it's small #55 releases the lock once no active checker remains.)

This is a dependency upgrade only — no apisix production code changes are required, because the fix belongs in the library.

Tests

t/node/healthcheck-stale-cleanup.t sets up two health-checked upstreams (each with two nodes), lets both checkers register their targets, then drops one node and changes the checks config on each upstream so the manager rebuilds the checker and delayed_clear()s the old target. It asserts, via /v1/healthcheck:

• probed_before: 2 — before removal both soon-to-be-dropped nodes are in the checkers' target lists, i.e. actively probed (covers bug: health check keeps probing stale upstream nodes after nodes update (checker cache not invalidated) #13141).
• stale_after: 0 — after the cleanup window the dropped nodes are gone from every checker, so they can be neither queried via the control API (bug: After a node is deleted from the upstream, its information can still be queried from the health check interface. #13385) nor probed (bug: health check keeps probing stale upstream nodes after nodes update (checker cache not invalidated) #13141).

A node present in a checker's target list is being actively probed, so the single /v1/healthcheck observation covers #13385 and #13141 together. The bug reproduces only with multiple upstreams (a single-upstream setup is always the "first" checker and cleans), which is why earlier single-upstream repros failed.

Verified locally against both library versions:

lua-resty-healthcheck-api7	result
3.2.1-0 (before)	FAIL — probed_before: 2 / stale_after: 1 (the second checker keeps its removed node)
3.2.2-0 (this PR)	PASS — probed_before: 2 / stale_after: 0

#13235 (periodic-lock release) is intentionally not tested here: it is a multi-worker lock-contention scenario that cannot be reproduced deterministically in apisix's single-worker test harness without becoming flaky. It is covered at the correct layer by the library's own regression test 20-periodic-lock-release.t in api7/lua-resty-healthcheck#55.

Scope / merge order

• This supersedes fix(healthcheck): update targets incrementally instead of destroy-and-rebuild #13582 for bug: After a node is deleted from the upstream, its information can still be queried from the health check interface. #13385/bug: health check keeps probing stale upstream nodes after nodes update (checker cache not invalidated) #13141/bug: healthcheck not work #13235. fix(healthcheck): update targets incrementally instead of destroy-and-rebuild #13582 has been closed; its incremental-sync rewrite targeted bug: Health check state lost and checker not working after upstream node changes #13282 (the destroy-and-rebuild nil-checker window), which is an orthogonal apisix-side concern handled separately in fix(healthcheck): reuse the checker on node-only upstream changes instead of destroy-and-rebuild #13629.
• The dependency is already released: feat: release v3.2.2 api7/lua-resty-healthcheck#56 is merged, tagged v3.2.2, and 3.2.2-0 is published on luarocks, so make deps resolves and CI is green.

Fixes #13385, #13141, #13235.

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

[membphis]

LGTM.