Name the data query reindex assert

[somethingwithproof]

Stacked on #595, which is stacked on #589. Merge in that order.

The data query reindex assert decides whether Cacti re-runs a data query. It was written out three times inside poll_host(), once per operator, each with the same twenty-four lines of logging and queueing wrapped around a one-line comparison.

The copies had drifted. The three REPLACE INTO poller_command statements are three spellings of the same SQL:

"... (poller_id, time, action,command) values (..."
"... (poller_id, time, action, command) ValueS (..."
"... (poller_id, time, action, command) VALUES (..."

Nothing else differed except the operator character in the log line.

What the assert actually does

reindex_assert_failed(op, assert_value, poll_result) returns TRUE when the assert has been violated. The relation is assert_value op poll_result.

Two details were load-bearing and easy to miss while this was spelled out three times:

• = compares as text, < and > compare as numbers. A device reporting 007 is equal to 7 under > and not equal under =.
• An assert_value of "0" never fails a < assert. That is the uptime case: a device that has not reported an uptime yet must not look like it rebooted. The guard is specific to <; it does not cover the other operators.

Equality is not a violation of either ordering operator, so > only fails on a strict increase.

None of that was written down anywhere. It is now in the function comment and pinned by tests.

Not a bug, checked

The < branch sits at a deeper indent than the other two and reads like it might be unreachable. It is not: it lives in a final else if (strcmp(reindex->assert_value, "0")), which is the "0" guard above. Worth stating because the indentation invites the wrong conclusion.

Tests

Eleven cases, reindex_assert_failed at 100% line coverage under gcov:

• = compares as text, including 007 against 7
• > and < compare as numbers, including 007 against 7 going the other way
• equal values fail neither ordering operator
• "0" never fails <, and the guard does not leak into =
• U and No Such Instance are treated as "assume the assert holds", case-insensitively
• an unrecognised operator does nothing
• NULL arguments are refused
• values past 32 bits compare correctly, which matters because sysUpTime is centiseconds and passes INT_MAX in under a year

Coverage across the extractions

Measured with gcov, not counted by hand:

reindex_assert_failed            100.00% of 14
poll_host_build_queries          100.00% of 29
poller_item_scope                100.00% of 6
poller_owner_scope               100.00% of 6
poll_host_release                  0.00% of 10
poll_host_release_connections      0.00% of 9
poll_host                          0.00% of 840

The two release helpers are the teardown from #595: db_release_connection() and mysql_thread_end(), neither of which has an observable result to assert. They are not covered and I am not going to pretend otherwise.

poll_host_build_queries reached 100% only after this branch added the active_profiles dimension. The first fixture pinned it at 1, so the multi-profile forms of query5 and query10 were never built. Those add AND rrd_next_step <= 0 so only items due this tick are polled.

Size

poll_host() is 1,516 lines, from 1,927 on develop. The chain itself went from 88 lines to 34.

60 of 60 tests pass. Clean ubuntu:24.04 build matching ci.yml, same four warnings as develop.

No CHANGELOG entry here; #578 is the changelog PR for this batch.

[somethingwithproof]

Consolidated into #597, which carries this branch's commits unchanged.

Every pair of these ten conflicted on tests/unit/test_linked.c because each appended to the same registration array, so whichever merged first would have forced a rebase on the other nine. #597 is one review and one approval for the same 20 commits, still one logical change each.

Nothing here is dropped. Reopen this if you would rather review it separately.