Report what a device fails to deliver to the controller

[eriknordmark]

Problem

A device reports application, volume, content tree, blob, network instance,
hardware and cluster state to the controller only when that state changes,
and nothing re-asserts it afterwards. So a report the controller does not accept
leaves its view of that object wrong until the object changes again - for a
steady-state application, indefinitely.

Nothing in the API says this is happening. zedcloudMetric.failures /
success describe whether the device could reach the controller, and EVE
deliberately counts a request the controller answered with an error as a success
there, because for connectivity purposes it is one. The result is that a device
sitting on undelivered reports, or one which has discarded them, looks identical
to a healthy device.

This is the telemetry half of lf-edge/eve#6302, where the device silently
discarded state updates on any 4xx or 5xx. lf-edge/eve#6304 fixes the discarding
and reports both conditions in the device log; these fields are what would let a
controller see them without reading device logs.

What this adds

Both additions are wire-compatible - new field numbers only.

deferredQueueMetric, at device level (deviceMetric.deferred_queue = 32).
The queue is per device, not per port: a message is not tied to the port an
attempt to send it happened to use.

field	meaning
undeliveredMsgCount	messages waiting to be delivered
oldestUndeliveredMsg	when the oldest was produced; the difference from now is how stale the controller's view may be
droppedMsgCount	messages given up on since boot
rejectedMsgCount	of those, ones the controller rejected outright
supersededMsgCount	of those, ones a later periodic publication supersedes
lastDroppedMsg	when the most recent one was given up on

The counter/timestamp pairing follows the existing failures/lastFailure
convention in the same message. It matters here because these counters live in
memory and reset when pillar restarts, so a controller differencing samples sees
a reset as a decrease, and because metric messages are themselves best-effort,
so samples get missed. A timestamp answers "was anything lost recently" without
either problem.

Three counters per URL (urlcloudMetric 10, 11, 12): retriableErrCount
for answers which may not repeat - a server error, a rate limit, a request
timeout - and rejectedErrCount for outright rejections, which is the
distinction that decides whether the device keeps a message or discards it.
Plus deliveredMsgCount, the messages the controller accepted: narrower than
sentMsgCount, which counts every message the server answered at all, including
the ones it refused. Both remain useful, since for connectivity purposes an
answer is a success whatever it says - so rather than redefine sentMsgCount,
which would break comparability across versions and which nim and diag read as
a connectivity signal, the accepted count is its own field.

An APICapability value, API_CAPABILITY_DEFERRED_QUEUE_METRICS = 23, so a
controller can tell "nothing was dropped" from "this EVE does not report drops".
Report-side capabilities have precedent: API_CAPABILITY_SMART_REPORT (20)
covers SmartAttr / smart_status in info.proto and
API_CAPABILITY_REPORT_TPM_EVENTLOG (21) covers the event log in attest.proto,
so only the value is added here - the enum's own description is left to #153.

Deliberately not included

• A per-status-code histogram. The controller already knows what it
  answered, so per-code counts from the device are largely redundant - except
  for codes injected between the two, such as a load balancer's 503 or a proxy's
  407, which the two class counters above still capture. Per port x per URL x
  per code, re-sent every metrics interval, is a lot of repetition for that.
• The type of the dropped message (which ZInfoTypes it carried). It is the
  natural next question for an operator, but reporting it would mean importing
  proto/info into proto/metrics, and that direction is off the table: it
  invites import loops, if not now then as either file grows. Duplicating the
  enum inside proto/metrics would drift, so the type is simply not reported.
  A controller that needs to know which object went stale can compare what it
  last heard per object against oldestUndeliveredMsg.

This change adds no imports at all.

Downstream

Populating these fields is a follow-up in lf-edge/eve (pillar's
controllerconn queue and AgentMetrics), after this lands and is vendored via
make bump-eve-api. No controller change is required to accept them.

[christoph-zededa]

I think they can be unsigned.

Also I thought we're using snake_case in our proto files.