Increase qemu test coverage

Closes #20, #18, #31, and #43

See merge request system-transparency/core/stprov!36

This ensures we can lint all commit messages, as opposed to getting a
failed CI job because no merge-base can be found in the shallow clone.

Credit: thanks to nisse for figuring out what the problem was here.

That /bin/sh works is because of some u-root symlink.  If one needs to
mock a more exotic operator, it is the elvish syntax that is expected.

We stop if something doesn't work, no need to print pass.  It made more
sense when the pass message was a kind of warning: "only checked URL".

This is somewhat important, because our Makefile will not fail if it is
trying to set a default Go variable that doesn't exist.  In other words,
if we change the name of a default variable without also updating the
Makefile correctly, it could come back to bite us and users later on.

Now we should catch this type of errors for all but the bond default.
It is considered out of scope because bonding is only tested manually.

Closes #18.

We ended up needing some of these parameters earlier for setup.

Credit: serve-http was adapted from an abandoned MR by nisse.

Note: QEMU's guestfwd option is broken on Debian stable, but works as
expected on Debian testing.  This is why QEMU is being backported here.

Closes #31.  Related to #18 (i.e., use of our Makefile in CI).

Allow users to set their own template URL at compile time, which is a
way to type less (omitting -r URL in favor of -u USER and -p PASSWORD).

To be determined if this is the right way to have templated URLs.  This
is the old "mpt way", which we should think twice about before dropping.

Closes #43.  Related to #36.

Helps avoid reliance on default QEMU settings that matter for our tests
without us knowing about it.  It may also challenge stprov a bit more.

Bumps up the test coverage, trying:
- Both static and dhcp
- The three ways to specify interfaces (autodetect, ifname, mac address)
- The two ways to specify host names (build from a constant, full host)
- The two ways to specify URLs (build from a constant, full URL)
- If we have reasonable things in EFI NVRAM for these combinations

Long term it might make more sense to test some of these things
somewhere else instead, but that would require refactoring.  In other
words, this is an attempt to get more coverage without too much work.

Update a few parameters to make the test pass.  We had the wrong
gateway; and is now not running with stprov's default DNS option.

To facilitate quicker (local) development cycles.

Helpful for manual stprov debugging.

Still no changes that affect the actual testing, just preparing so that
we will be able to write better tests that do exactly what we think.

Note that the current test passes despite the gateway being wrong.  In
other words, stprov is guessing .1 but QEMU's default gateway is .2.  No
test fails because we are only communicating via a port forwarding rule.

Just wrapped as a loop, still no changes to what we're testing.

No changes in test behavior so far, just cleaning up so that we can more
easily loop over multiple configurations to increase our test coverage.

Doesn't change the actual test, but reads better in my opinion.

This makes it a bit easier to understand these (similar things) once.

This commit is a preparation for cleanly testing that all values in the
host configuration are as expected.

Fail if setups fails, otherwise continue and run the actual tests.

refactor(internal/st): use stboot's hostcfg

See merge request system-transparency/core/stprov!29

We used to have separate setup functions to produce and test valid host
configurations for different configurations: static, dhcp, and bonding.
The idea for them was: have something smaller that we can unit test.

Exactly how good these units tests were is a separate question.  Anyway.

Over time, these setup functions were not maintained.  Configuration
options were instead added directly in "main", and the logic to do a
correct setup are spread out all over the place.  As of the recent move
to using stboot's implementation of host configuration, these setup
functions were deemed obsolete and have been removed.  This commit also
removes the tests that were intended for these isolated setup functions.

Note that the internal reading and writing of EFI NVRAM is still being
tested separately from the removed unit test.  And that our qemu tests
try the path of json (un)marshalling with stboot's host configuration
package, then reading/writing with our internal EFI NVRAM reads/writes.
So in terms of actual test coverage we havn't really removed anything.

As an aside, the deleted tests did not run anymore.  The motivation for
deleting rather than fixing is (again) because they didn't add anything.

(What stprov really needs is refactoring to be more testable.  And this
is not the right time to get started with that type of refactoring.)

Used to be set in NewBondingHostConfig, which no longer exists in stprov
as of the transition to stboot's implementation of host configuration.

Note that bond name was not added by NewBondingHostConfig before, but it
is being written as of the refactoring by Kai.  This is the behavior we
want, but it stands out that stboot has worked without this until now.
A dependency of stboot likely defaults to "bond0", i.e., the same and
commonly used bond name that stprov sets (without being configurable).