Support customizing proxy settings for rootfs fetch

[bgilbert]

When the OpenShift Assisted Installer configures the minimal ISO for a user, it needs to inject user-specific network proxy configuration for fetching the rootfs. Currently this is done via a systemd drop-in for coreos-livepxe-rootfs.service, in an appended initrd, that sets the appropriate environment variables for curl(1). We'd like the AI to switch from custom tooling to coreos-installer subcommands, so we'll need to support this natively.

AI would like to generate the minimal ISO once per release image, and inject all user-specific customizations while streaming an ISO download to the client. Therefore we can't add the proxy settings to the embed area during iso extract minimal-iso and we can't just add a separate low-level subcommand; we need an iso customize option so the AI backend can stream all customizations to stdout in one pass.

We'll need to decide how broadly to perform proxy configuration. AFAIK there are two things in the initrd that care: Ignition (which already has the ignition.proxy config fields) and rootfs fetch. Potentially we could also configure proxy settings in the real root. Options include:

1. Configuring proxies only for rootfs fetch, e.g. iso customize --live-rootfs-proxy. That option seems very specific to a particular OS feature.
2. Configuring proxies for both the rootfs and Ignition, by setting ignition.proxy plus environment variables for coreos-livepxe-rootfs.service. Like option 1, this means that coreos-installer would know about coreos-livepxe-rootfs.service, which seems awkward. The Ignition noProxy field seems to be a superset of the NO_PROXY env var as supported by curl; we could define the option to accept the common subset of both syntaxes. We could choose to affect only the live system (--live-*), or also inject proxy settings into the dest Ignition config. And finally, it'd be hard to explain what this option actually does, for option naming and docs.
3. Option 2, but setting proxy env vars initrd-wide. This is a bit easier to explain, but makes it harder to define semantics for affecting the dest system. With option 2 we'd only need to affect the dest Ignition config, since there's no live rootfs fetch; here, we'd need to either explicitly exclude the dest initrd from scope, or go to some effort to inject an appended initrd with the proxy configuration into the dest system after coreos-installer runs.
4. Option 3 plus automatically configuring proxies in the real root. This seems very broad; the user might want different settings in the real root, and can always just configure their Ignition config accordingly.

@carbonin reports that this is not urgent, since AI will still need to carry its legacy codepath for RHCOS releases older than 4.10.

cc @carbonin @jlebon