Report a dropped queue entry as it happens, with the correlator and not the item (#47)

[iderex]

The issue this belongs to

Belongs to #47. Neither of that issue's two conditions is met here, and the
reason is unchanged: both restart the core and restore a server, and nothing in
this tree does either. What this closes is the third item on that issue's own
list of what is not covered - nothing reports a drop as an event.

It touches four files two other issues own, and none could be separated from it.
src/playback/report.rs is #57's and src/session/mid_playback.rs is #35's,
because the enqueue that makes the report is theirs to call.
src/lifecycle/mod.rs is #115's, because 0071's rule as data is gathered where
the core is created and a field name declared and not stated is refused by the
suite. tests/the_rule_as_data_names_every_field.rs is #71's, and it pins the
whole set a bundle would carry rather than a count, so a name arriving is a name
written into it.

What changed

A drop at the bound is reported through 0100 at the moment it happens, with the
kind of action and the correlator 0071 defines for the target.

The enqueue makes that report itself, and this replaces handing the drop back for
somebody else to make it. Handing it back left the record's "every drop" resting
on every caller remembering, and a caller that ignores the answer produces exactly
the silent discard 0047 exists against. The value is still handed back, because a
caller may want to say something of its own about what was lost.

At failure rather than notice. That is 0105's sentence about a dropped queue
entry and its reason:

git show origin/main:docs/decisions/0105-an-entry-this-version-did-not-write.md | grep -n -A5 'A dropped queue entry is reported at'
161:A dropped queue entry is reported at `failure` rather than at `notice`, and it
162-counts into the standing drop count 0047 already keeps for entries displaced at
163-the bound. Silently discarding a person's action is the failure 0047 exists to
164-prevent, and a drop for a bad envelope is that same discard arriving through a
165-different door. It reaches the same counter so that a client reporting what was
166-lost reports one number rather than two that have to be added up by whoever reads

The target leaves as for-target, reduced, so the diagnostics boundary turns it
into a correlator and the identifier reaches no sink. The kind leaves as
asserted-about, carried whole, because it is one of a fixed set this module
declares and two people running the same build against the same server cannot
hold different values for it, which is 0068's question and the one that first
treatment is for.

The order the dropped entry stood in is on the value handed back and not on the
event. 0047 names two things the report carries, and a counter meaningful only
inside one queue is not one of them.

Reporting::report, Reporting::observe, Reporting::report_after_a_renewal and
the enqueue itself take the facility, for the reason they already take a clock
reading: this module owns no facility of the client's and reaches for nothing.

What failure it prevents

The one 0047 opens with. A person marks something watched on a train, the queue
is full a month later, and the oldest thing they did is discarded to make room.
The count answers somebody who asks afterwards; the event is what reaches a client
that was listening, and without it a client can report that eleven things were
lost and never which kind or how they clustered.

The second failure is the one the shape prevents rather than the field. A drop
handed back as a return value is a drop reported only where a caller remembered,
and nothing here made remembering necessary: the enqueue carries no #[must_use],
and both callers in the tree pass its answer straight through to their own return
without reading it.

git show origin/main:src/server/write_queue.rs | grep -n -B2 'pub fn enqueue'
406-    /// on the person who used the application most, which is the same person
407-    /// coalescing at enqueue exists to protect.
408:    pub fn enqueue(

Neither failure has happened, because nothing here has a sink at that point yet,
and both are stated as what the record argues against rather than as an
incident.

Evidence

The commit being pushed:

git rev-parse HEAD
80882f0aa7fd3048618ca99c508f37e153849ca4

The two commands CONTRIBUTING.md names, run at it:

cargo build --locked --all-targets
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 4.28s

cargo test --locked
test result: ok. 586 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
test result: ok. 11 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
test result: ok. 28 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
test result: ok. 125 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

Two cases are new in the module:

git show origin/main:src/server/write_queue.rs | grep -c '#\[test\]'
20
grep -c '#\[test\]' src/server/write_queue.rs
22

Four gate legs run by hand on this machine:

bash .github/format/format.sh check
Every tracked source file above is written the way the formatter would write it.

bash .github/lint/lint.sh check
Every lint the groups above carry was refused, outside the register printed with it.

bash .github/invariants/invariants.sh check
Every rule above was applied to its subject and refused nothing.

bash .github/doc-paths/doc-paths.sh check
Every path these documents name resolves against the tracked set.

What a guard here refuses, and the proof it bites

Three violations, each watched failing. Every run is
cargo test --locked --lib server::write_queue, and the green run at the head is:

test result: ok. 22 passed; 0 failed; 0 ignored; 0 measured; 564 filtered out

a_drop_report_carries_a_correlator_and_never_the_identifier refuses the item
a person watched reaching a sink. The violation is one word at the declaration,
which is where 0071's treatment is chosen:

-pub(crate) const FOR_TARGET: FieldName = FieldName::reduced("for-target");
+pub(crate) const FOR_TARGET: FieldName = FieldName::carried_whole("for-target");

test server::write_queue::tests::a_drop_report_carries_a_correlator_and_never_the_identifier ... FAILED
the identifier reached the sink as an-item-nobody-should-read-0
test result: FAILED. 21 passed; 1 failed; 0 ignored; 0 measured; 564 filtered out

a_drop_is_reported_as_it_happens_with_the_kind_and_a_correlator refuses the
severity a client filters out:

-                Severity::Failure,
+                Severity::Notice,

test server::write_queue::tests::a_drop_is_reported_as_it_happens_with_the_kind_and_a_correlator ... FAILED
test result: FAILED. 21 passed; 1 failed; 0 ignored; 0 measured; 564 filtered out

Both of them together refuse the shape this change replaces, which is the drop
handed back and never reported:

-            diagnostics.emit(
-                Severity::Failure,
-                AN_ENTRY_WAS_DROPPED,
-                &[ ... ],
-            );
+            let _ = diagnostics;

test server::write_queue::tests::a_drop_is_reported_as_it_happens_with_the_kind_and_a_correlator ... FAILED
test server::write_queue::tests::a_drop_report_carries_a_correlator_and_never_the_identifier ... FAILED
test result: FAILED. 20 passed; 2 failed; 0 ignored; 0 measured; 564 filtered out

The first case also asserts the negative half, that a queue under its bound
reports nothing, so the guard cannot be satisfied by a facility that emits on
every enqueue.

What this does not cover

The standing count is unchanged and was already here. This adds the event beside
it, and nothing about WriteQueue::dropped moved.

No drop of any other kind is reported, because there is no other kind. 0105 gives
a second door - an entry whose envelope does not open - and that door needs bytes
in a store, which is #40 and #41 and is not built.

Nothing calls the enqueue with a sink attached. The two callers in the tree are
crate::playback::report and crate::session::mid_playback, and both are reached
only from cases; the client surface that would hold a real facility is #115 and is
not built. So the event is proven against a collector here and has reached nobody.

The event's identity is this module's, which is where 0100 puts it, and no
document lists it. What derives the set of identities is nothing: there is no
EventName::all, by 0100's own decision that a central set would put every
subsystem's identities in one file. That is stated rather than fixed here.

Nothing measured anything.

The coverage leg and the thread detector were not run on this machine. The
verdicts on this pull request are theirs.

Who has read it

Nobody other than me. There was no second reader available, and the evidence
above stands in place of one.