The trusted=yes that is refused is one on the project archive

[marcos-mendez]

Follow-up to tracker#7, on top of the verification fix merged an hour ago.

bin/keel-archive-check refused a trusted=yes on any apt source in the
build tree. The captured pool of decision 0012 sets Trusted: yes on purpose:

# A file: URI, because a build must not depend on a server or on the
# network. Trusted, because the index is written on this machine from
# these files; apt still checks every package against the sha256 the
# index records, and keel-pool verify checks the pool against the same
# digests.

So the wider rule would have failed every pinned build. /srv/keel-pool/current
does not exist on the build host at the moment, which is the only reason
tonight's rebuild did not hit it.

What is refused is now a source that names the project archive and switches
verification off, which is the defect of tracker#7, in whichever file and in
either of apt's two formats. What the pool does is the pool's business: its
index is generated on the build host and its digests are checked twice.

Test plan

• 27 bats tests for bin/keel-archive-check, three of them new: the pool's
  Trusted: yes passes, a trusted=yes on the project archive in another
  file fails, and the archive the rule applies to is overridable
  (KEEL_ARCHIVE_PATH)
• bin/keel-archive-check 100 percent (54/54) under kcov
• shellcheck -S warning bin/keel-archive-check clean
• COVERAGE_THRESHOLD=95 tests/coverage.sh: 99.66 percent (297/298) over 134 bats tests