[FR] Expose retry-attempt observability (hook/event) — retried 503s and per-attempt latency are invisible to callers

Bắt đầu với hành vi retry được tham chiếu trong chú thích mã của api-request và xem xét các tùy chọn nhắn tin hoặc ứng dụng được thảo luận trong yêu cầu, cùng với issue liên quan #1615. Công việc được xem là hoàn tất khi các caller có thể quan sát các lần thử retry, thông tin chi tiết về status hoặc lỗi, thời gian đã trôi qua và liệu một lần retry khác có xảy ra hay không, mà không cần patch các thành phần nội bộ của HTTP/2.

Is your feature request related to a problem?

The HTTP clients retry transient failures — per the code comment in api-request, "Retries up to 4 times on connection reset and timeout errors as well as 503 errors" — which is great, but the retry lifecycle is completely invisible to the caller. You observe only the final result and total elapsed time.

In production this matters a lot for FCM:

• A sendEach() call that "took 15s" is indistinguishable from one that made three 5s attempts. Capacity planning, SLO attribution, and incident analysis need to tell these apart.
• 503s that the SDK retries away never appear anywhere. During an FCM backend hiccup, our error rate looked flat while the wire was full of retried 503s — we only learned this after instrumenting below the SDK.

What we did as a workaround (and what it revealed)

We attached listeners at the HTTP/2 layer to record, per attempt, the :status header the SDK already receives, plus per-attempt request→response duration. Two things became visible immediately:

1. Swallowed 503s during backend episodes (invisible at the SDK surface).
2. Batches with ~15s total latency decomposed cleanly into 3 × ~5s attempts — i.e. the tail was retry behavior, not slow single requests.

We validated the accounting at scale: in a ~650k-message load run at ~2,000 rps, wire-level attempt counts reconciled exactly with SDK-level result counts (596,663 = 596,663).

Monkey-patching works but is version-fragile and clearly not the intended way.

Describe the solution you'd like

Any of these would solve it (in rough order of preference):

1. An onRetryAttempt(info) callback / EventEmitter on the messaging or app options, with { attempt, statusCode?, errorCode?, elapsedMs, willRetry }.
2. Attempt metadata attached to the final response/error (e.g. attempts: [{status, elapsedMs}, ...]).
3. At minimum, a debug logging hook for retry decisions.

Describe alternatives you've considered

• Runtime-patching the HTTP/2 request path to observe response headers (works, but couples us to SDK internals).
• enableLegacyHttpTransport() + external proxy metrics (gives up HTTP/2).

Additional context

Related: #1615 (custom RetryConfig) — configuration and observability of the same mechanism. Verified against 12.7.0 and 14.1, on Node 16 and 24.