bug(tests): the backup examples carry seven copies of their wait helpers, already in three variants #3757

Every directory under examples/backups/ ships its own 00-helpers.sh, and each defines wait_for_field from scratch: clickhouse, etcd, foundationdb, mariadb, nats, postgres and vmi. Comparing the seven function bodies gives three distinct implementations, so the copies have not merely been duplicated, they have already drifted.

The split is clickhouse, etcd, mariadb and postgres on one body; foundationdb and nats on a second; vmi on a third. The difference between the first two is not cosmetic: the first accepts a seventh argument naming a terminal failure value and returns as soon as the field reaches it, where the second has no such branch and polls to the full timeout. A caller reading one directory's helper cannot assume anything about another's.

wait_hr_ready is duplicated more narrowly, in mariadb and postgres only, and those two are byte-identical.

How I checked

Extracted each function body with the brace at column zero as the terminator and compared texts and checksums, rather than diffing whole files: the files legitimately differ in their app-specific variable blocks, which hides the shared parts. Measured against main, not against an older branch point. I first grouped these from a merge base a few days old and put clickhouse in the wrong group, because its helper had gained the terminal-value branch in the meantime.

What it already cost

A change to the diagnostics inside wait_hr_ready had to be hand-carried from one copy to the other. The transfer was scripted against "the first if [[ $elapsed -ge $timeout ]] block", and that regex matched the wrong function: wait_for_field's timeout branch, not wait_hr_ready's. The result compiled and read plausibly while referring to $resource_type, $resource_name, $current and $desired, none of which exist in wait_hr_ready's scope, under a script running set -euo pipefail. It would have aborted the postgres harness with an unbound variable at the moment it tried to report a failure, on the diagnostic path the change was improving.

It was caught by reading the diff before the change was committed, so nothing broken reached the tree. It was caught by reading, though, not by any check: nothing here compares the copies, so a divergence introduced this way would be invisible until the affected example ran and failed for an unrelated-looking reason.

What this issue is not asking for

Whether the right answer is a shared file, a symlink, generation, or leaving them apart deliberately is a decision for whoever owns these examples, and it interacts with the fact that each directory is meant to be readable on its own by a human following the walkthrough. This issue records that seven copies exist, that three variants already exist among them, and that keeping them in step is currently manual and has already gone wrong once.