[zmqclient]: Add send-path back-pressure counters and a retry-ladder cap

[deepak-singhal0408]

What I did

ZmqClient::sendMsg() drives the ZMQ socket in non-blocking mode and, when the socket is full (EAGAIN) or transiently unready (EINTR/EFSM), retries with an exponential back-off ladder. Today that back-pressure signal is only logged and then discarded, and the ladder length is fixed (MQ_MAX_RETRY → ~41 s worst case on a single message).

This PR makes that signal observable and the inner wait boundable, without changing default behavior:

• Four process-local, per-instance atomic counters incremented at the branch points that already fire, exposed via inline getters:
  • getSendEagainTotal() — EAGAIN / HWM back-pressure (the leading indicator)
  • getSendRetryTotal() — retry iterations (EAGAIN + EINTR/EFSM)
  • getSendBackoffMaxMs() — running max of the clamped back-off delay
  • getSendLadderExhaustedTotal() — inner ladder exhausted → throw
• setSendRetryConfig(maxRetries, maxBackoffMs) — optional cap on the inner ladder. Defaults (maxRetries < 0, maxBackoffMs < 0) preserve the exact historical behavior for every existing producer. A producer that owns an outer retry/coalescing loop can shorten the ladder so control returns quickly instead of blocking on one message.

ZmqClient stays DB-agnostic — it only counts and exposes getters; the owner decides where/how to publish.

Why

This is the transport-layer half of the fix for sonic-buildimage #28369 (fpmsyncd ZMQ route drop under burst). The send-path back-pressure that precedes a drop is currently invisible; these counters let a producer surface it as a leading indicator, and the retry cap lets a producer with its own outer loop avoid the ~41 s inner block that would otherwise defeat coalescing. The consuming fpmsyncd change is a follow-up sonic-swss PR.

ABI

Getters and atomics are appended as trailing members; ZmqClient is only ever held by reference/pointer (never embedded by value), and the class is already non-copyable, so the change is ABI-additive.

How I tested

New ZmqClientSendPathCounters unit tests in tests/zmq_state_ut.cpp:

• Fill a peerless PUSH socket's send queue to force deterministic EAGAIN → retry → ladder-exhaustion, and assert each of the four counters advances to its expected value (with a small setSendRetryConfig cap so the test runs in <50 ms instead of the default ~41 s ladder).
• Guard that the accessors read zero before any send (ABI-additive accessors compile/link and initialize correctly).

Full swss-common ZMQ unit-test suite: 18/18 pass, 0 regressions.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

This PR enhances swss::ZmqClient’s send-path observability by adding per-instance atomic counters for ZMQ back-pressure/retry behavior and introducing an optional configuration API to cap the internal retry ladder, with accompanying unit tests to validate counter behavior under forced retry conditions.

Changes:

• Added setSendRetryConfig(maxRetries, maxBackoffMs) to optionally bound the internal retry/backoff ladder.
• Added four per-instance atomic counters with inline getters to expose EAGAIN/retry/backoff/ladder-exhaustion signals.
• Added unit tests to force a retry/ladder-exhaustion scenario and validate counter increments and initialization.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
common/zmqclient.h	Adds retry-cap API, send-path counter getters, and new member state for caps/counters.
common/zmqclient.cpp	Implements retry-cap setter and increments/records counters on retry/backoff and ladder exhaustion.
tests/zmq_state_ut.cpp	Adds unit tests to validate counter behavior and default initialization.