fix(evpp): reconnect stats correct in onclose during a failing retry loop (follow-up to #862)

[ithewei]

Follow-up to #862 (#615). #862 merged an earlier revision of the reconnect-stats change; the final refinement discussed on the issue didn't make it in. This PR completes it.

Problem in the merged version

isReconnect() returned reconn_success_cnt_ > 0. So while auto-reconnect is still failing (no successful reconnect yet), isReconnect() reads false in onclose — which is wrong when the user is asking "am I in a reconnect loop?". It also only counted on success, so lastReconnectRetries() was 0 during the failing loop.

Fix

Track the cycle via reconn_retry_cnt_, updated when an attempt is scheduled (in startReconnect), not only on success. It mirrors reconn_setting->cur_retry_cnt but survives the reset done on a successful connect, so the state is correct in all three timings.

bool     isReconnect();            // reconn_retry_cnt_ > 0
uint32_t reconnectRetries();       // attempts in the current reconnect cycle
uint32_t reconnectSuccessCount();  // number of successful auto-reconnects

Renames the just-added lastReconnectRetries() → reconnectRetries(), because its meaning is now "attempts in the current reconnect cycle" (updated on schedule, valid during the failing loop), not "failed attempts before the last success". Since #862 landed very recently, adjusting this name now avoids shipping the confusing semantics. Stats reset in setReconnect(NULL) (which closesocket() also does); reconfiguring with a non-NULL setting keeps them.

Verified

(1) first onConnection:  isReconnect=0
(2) failing onclose:     isReconnect=1 retries=3 success=0
(3) reconnected onConn:  isReconnect=1 success=1
ALL PASS

make libhv builds clean.

[Copilot]

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