The store accepts a known plan digest for a row and keeps that plan alive (inert, #5158)

[erikdarlingdata]

Part of #5158. This is the second of three PRs, and it changes no behavior: no collector passes a digest yet.

Why

#5158 stops query_stats from re-rendering plans the store already holds. A row whose plan the host has already stored will carry only the plan's content digest. The store has to write that digest straight into the row, with no content, and keep the plan's dimension row from aging out while rows still reference it.

What changes (PerformanceMonitor.Darling.Storage)

• PgCollectorRowWriter.PayloadOrDigest(content, knownDigest):
  • with a known digest and no content, it writes the digest into the row's digest column, adds the digest to the batch's touch set, and inserts no dimension row;
  • every other call takes today's Value(content) path;
  • a malformed digest throws: it must be hex and exactly PayloadDimensions.DigestLengthBytes (32) bytes. So does a known digest at a payload position with no dimension diversion, which would otherwise write a row with no plan, silently.
  • The digest is PayloadDimensions.Digest's own output, held by the host. Nothing re-derives it.
• PayloadDimensionBatch keeps the touch set per dimension table, deduplicated and in digest order. IsEmpty counts it.
• PayloadDimensionWriter.FlushAsync runs one more statement per dimension table, in the batch's transaction (PayloadDimensions.TouchSql):
  • it refreshes last_seen for the touched digests older than the existing 6-hour guard. It uses FOR UPDATE SKIP LOCKED: the upsert and the touch are two locking statements, so no single lock order covers both, and two batches that each upsert one stale digest and touch the other's would otherwise deadlock. Skipping a row is safe, because whoever holds it is refreshing it (an upsert, another touch, or query_store's touch). A holder that rolls back is retouched next cycle. The dimension sweep can't be the holder, because it only reaches rows at least the guard plus a day old;
  • it returns the touched digests that have no dimension row;
  • FlushAsync returns those as a list of upper-case hex digests (compare case-insensitively) and logs their count at Debug. This PR doesn't act on the list; the next PR uses it to forget those digests, so the plan is fetched again. A digest still being inserted by another, uncommitted batch can be reported absent, which costs one extra render.
• Why the plan stays alive: a referenced digest gets its last_seen refreshed at least every 6 hours, which is the same guard the insert path uses. That keeps it inside the dimension sweep's liveness window, as it is today.

Tests (PayloadDigestPassThroughLiveTests, live store, 8 facts)

• A digest-only row resolves its plan through v_query_stats the same way a row written with content does: one dimension row, two fact rows on one digest.
• The 6-hour guard: at 5 h 59 m last_seen stays put; at 6 h 01 m it moves to the batch time.
• An absent digest is reported back, and its row reads a NULL plan without an error.
• Content plus a digest stays on the ordinary path: nothing is touched or reported.
• A malformed digest throws, and so does a known digest at a position with no diversion.
• A lower-case known digest round-trips, and the absent list reports it upper-cased.
• Two batches, two connections: each upserts one stale digest and touches the other's. Neither waits, neither deadlocks, and both commit. It uses the real upsert and touch SQL, with lock_timeout at 2 s and no sleeps.
• Mutation checks, each reverted:
  • writing the digest as NULL fails 2 facts;
  • removing the 6-hour guard fails the guard fact;
  • removing SKIP LOCKED fails the two-batch fact with a lock timeout (55P03).
• Checked against the collector change: the class also passes on a local merge with query_stats can fetch plan XML in a second target query for only the rows that need it (inert, #5158) #5173. The test writer forwards the row's own known digest.

SECTION: None (inert; the user-facing entry ships with the PR that turns it on)