This fixes the run package's leaky abstraction; other packages no longer
need to know or care that run.Config even exists.
Note that since the various Steps now depend on having a non-nil pointer
to a run.Config, it's unsafe (or at least risky) to initialize them
directly. They should be created with their NewSTEPNAME functions. All
their fields are now private, to reflect this.
This is the first step toward removing run.Config entirely. InitKube was
the only Step that even used cfg in its Execute function; the rest just
discarded it.
Now that the InitKube initialization happens inside its own package, the
private .values field can be populated at the same time, rather than
having to wait for Prepare().
Also clarified the config/template filename fields (configFile vs.
ConfigFile was particularly ambiguous).
This seems to be be a more natural separation of concerns--the knowledge
of which config fields map to which parts of a Step belong to the Step,
not to the Plan.
It's a little tricky to find a balance between "brittle" and "thorough"
in this test--I'd like to verify that e.g. the certificate is in
clusters[0].cluster.certificate-authority-data, not at the root. On the
other hand, we can't actually show that it's a valid kubeconfig file
without actually *using* it, so there's a hard upper limit on the
strength of the assertions. I've settled on verifying that all the
settings make it into the file and the file is syntactically-valid yaml.
This change revealed more about how the system needs to work, so there
are some supporting changes:
* helm.upgrade and helm.help are now vars rather than raw functions.
This allows unit tests to target the "which step should we run"
logic directly by comparing function pointers, rather than having to
configure/prepare a fully-valid Plan and then infer the logic’s
correctness based on the Plan’s state.
* configuration that's specific to kubeconfig initialization is now part
of the InitKube struct rather than run.Config, since other steps
shouldn’t need access to those settings (particularly the secrets).
* Step.Execute now receives a run.Config so it can log debug output.
