A boot test that proves the declared password, and the coverage gate

[marcos-mendez]

The gate this repository was bootstrapped with measured nothing: threshold
0 is test-shell.yml's bootstrap case, which exists so main can be protected
before the tests do. This raises it to the measured number and adds the
acceptance test.

What a boot test has to prove here. An appliance whose whole purpose is a
database is not proved by a listening port: the database listens whatever
password it ended up with, and keel diff never compares secrets, on either
side, so nothing else would notice a declared password that did not
arrive. So tests/boot-test.sh runs the declarative path end to end and the
verdict is a client connection:

1. keel pull and keel assemble the published chain (core, postgresql)
   into an LXC rootfs;
2. a random password is written to etc/keel/secrets/db_password (0600)
   and tests/instance.yaml, which declares secrets.db_password from that
   file, is installed at both paths the first boot reads;
3. keel spec apply renders it into etc/inithooks.conf, and nothing else
   is configured by hand;
4. the container boots and the first boot runs through the inithooks
   runner alone, which is where common's firstboot.d/35pgsqlpass reads
   DB_PASS and this layer's 36pgsqlverify checks it;
5. psql --username=postgres --host=::1 --port=5432 --no-password
   --command='SELECT 1' inside the container, with that password in
   PGPASSWORD. The password comes from the file written in step 2 and
   from nowhere else, so a row back is the proof that the description
   carried it to the database. --no-password makes psql fail rather than
   prompt, so a password that did not arrive is an error and not a hung
   test;
6. webmin-postgresql is installed and Webmin answers over IPv6 on 12321,
   because batteries included is a property of this distribution and a
   panel without its database module is a failed boot;
7. keel diff --root --spec reports no drift.

Its logic is in tests/lib/boot-test-lib.sh, the same shape as keel-core,
keel-nodebb and keel-mariadb, with the verdicts this layer adds;
boot-test.sh is the thin main that touches the system.

Measured, 58 bats tests:

overlay/usr/lib/inithooks/lib/postgresql.sh 100.00 (41/41)
overlay/usr/lib/inithooks/firstboot.d/36pgsqlverify 100.00 (15/15)
tests/lib/boot-test-lib.sh 100.00 (141/141)

100 percent over the three (197/197), which is the threshold. It is only
ever raised (decision 0006).

The hook tests run 36pgsqlverify for real against scratch directories with
every system command stubbed, and the psql stub answers the probe only for
the password the description declared, the way a server does. They are
about the half of the password defect that is this layer's: the declared
password is proved against the database, a password the database refuses
fails the hook, an answer that is not the probe's fails it, nothing
declared fails naming the field and never prompts, a PGSQL_PASS in the
conf is ignored because it is a build time variable, and APP_DB_USER
renames the role while a name that would need quoting is refused before
anything runs. 35pgsqlpass and bin/pgsqlconf.py belong to the common fork
and are measured there.

Stacked on #1; GitHub retargets it to main when #1 merges.