test(verify): run every operator both ways and report what it did - #8362

What changes were proposed in this PR?

The runner discovers the operators that implement the trait, configures each
from its schema, runs it through the engine and through its generated script,
and compares. An operator that cannot be run is reported as a row with the
reason rather than passed over, since an operator missing from the report is
a fact the report has to carry.

OperatorBehaviorSpec is what turns that into tests: one per operator per
configuration its schema offers, named so a single operator can be run alone.

Every operator reads one canonical table, and it now also carries the values a type reaches only at its edges. That means a double at 1e7 and past it, and one under 1e-3, which Java writes in E notation. It means timestamps in 1600, 2262, 2500 and 9999, outside pandas' nanosecond range. And it means text of digits with leading zeros, which a reader must not take for a number. Without them, a difference that only shows at those values is never asked about. It also carries views, its one LONG column, with counts past 2^31 on both sides of an int's limit.

Bullet and Gauge are compared by the figures their script writes, now that it writes every one rather than the first.

A whole workflow is compared too. WorkflowParitySpec, in amber's integration tests, runs each plan in the engine and through its translated script, and compares every leaf. Rows compare as a set unless the leaf's operator declares an order, since the engine runs most operators on several workers. Every plan reads the shared table, written at run time as the CSV the CSV source reads, once whole and once with a hole in every column. The plans are aimed at how fragments go wrong together: a chain, a cast to text, a Union of two halves that share no row, both branches of a Split, a holed integer column, a cast date, and a column named like a placeholder. File Scan reads the shared table's own file from the path Text Input names. TranslatedPlanRunSpec keeps the two the engine has nothing to compare with: two charts in one plan, and a chart that cannot be drawn.

amber's tests take the compiling service's and workflow-operator's classes and test resources, not the modules themselves. The compiling service brings dropwizard 4, which would evict the dropwizard 1 amber is built on.

Runs whose reason is that both paths raise are no longer skipped. They sit in their own list, variantsBothRefuse, run like any other, and pass only when the engine and the script both refuse, since a script that answers where the engine refuses is as wrong as a different answer. Only a run named there may pass on two errors, so a broken environment cannot turn the suite green. The one exception found is the dummy classifier on an empty table: it fits on nothing into a model that cannot predict, so it stays in variantsNotRun with that reason. File Scan reads the canonical table's own JSON, which both paths refuse as an archive and as a typed line, so those variants are listed there too. Its archives and typed lines are compared on real files, in the scenarios #8364 and #8363 add. A large binary is written to object storage, which the harness does not give the executor, so that variant is in variantsNotRun.

Any related issues, documentation, discussions?

Part of #8325, 23 of 27; that issue lists the set in order. It does not compile until #8357, #8358, #8359, #8509, #8363 and #8388 land. It calls PyOpExecHarness from #8357, StandaloneRunner from #8358, Comparator from #8359, the two chart comparators from #8509, CuratedHandlers from #8363, and ConfigGenerator.generateVariants from #8388, which builds on #8361. The edge values pass only once #8341, #8704, #8357, #8709, #8710 and #8597 are in. Each of those fixes how one path reads or writes them. All of them come earlier in the set or merge before it. An empty table runs on every operator once #8766 is in, which hands a port that carried no rows its declared columns.

Closes #8425, the task this change is the whole of.

The workflow-level comparison answers the review that asked for plans run end to end. It calls runTranslated from #8358.

Reading the shared table across a whole plan found two engine defects that the per-operator runs cannot reach. #9074, where result storage moved a timestamp before 1883, is fixed by #9076, which these plans need. #9077, where a Python operator pauses the run on a LONG column holding a null and a value past 2^53, is still open, so the chain projects before its sort until it is fixed.

How was this PR tested?

The tests in this change cover it. The whole set is exercised together once the last piece lands: every operator run through the engine and through its generated script, and the two answers compared.

Was this PR authored or co-authored using generative AI tooling?

Generated-by: Claude Code (Claude Opus 5, Claude Opus 5.5)