New package for internal kickstart customizations.
Adds support for user kickstart file contents.  We will also use it to
move other kickstart related options as a single struct across pipeline
generation code.

The osname property is only relevant for ostree installers.

Remove all the kickstart-related properties from
AnacondaInstallerISOTree and add the new kickstart.Options struct.
Panic if it's not set and any of the stages require it, for example to
set the path of the file when a kickstart file is required for the
specific payload.

This commit has no effect on generated manifests.

Remove the Users and Groups properties from AnacondaInstaller and add
the new kickstart.Options struct. Name it InteractiveDefaultsKickstart
to make it clear that it's not the same kind of kickstart file that we
create in the AnacondaInstallerISOTree but it only serves to set options
in the interactive default kickstart file. It currently only supports
Users and Groups.

This commit has no effect on generated manifests.

Adds a new blueprint customization [installer.kickstart.contents] that
will allow users to inject their own kickstart file into the ISO.

Pass the user kickstart customization from the blueprint options into
the pipeline generators and append it to any hardcoded kickstart bits
that we might be including ourselves.  Just like with other injected
kickstart parts, like the %post section we add for sudoers, the user's
kickstart file, when specified, will be added to an iso as osbuild.ks
and the kickstart file created by osbuild will be renamed to
osbuilld-base.ks and run using an %include added to the top of the
osbuild.ks file.

Instead of a static content hash for the raw kickstart file when
testing, calculate it on the fly using a hardcoded blob for the sudobits
and add any extra content that the user might have supplied so we can
test the user injected content as well.

Check the input instead of passing true/false for every test.

The user kickstart contents is identical to the contents added when the
sudo-nopasswd options are enabled, so this configuration produces the
same manifest as the unattended-iso configuration.

Error out at the blueprint processing if the user includes a custom
kickstart and also includes installer customizations.

User and Group customizations are incompatible with kickstart contents
for ostree Anaconda installers only.
When building an ostree Anaconda installer (edge-installer or
iot-installer), users and groups are created using kickstart commands.
When the user adds their own kickstart file contents, we want to remove
any ambiguity or confusion by not allowing any other customization that
would affect the kickstart file.

Do not allow or add any kickstart options to the bootc container
installer ISO when a user kickstart is included.
The only line that we add is the ostree container installation line in
its own kickstart.  The user kickstart file is then added separately and
it %includes our own.

Do not allow or add any kickstart options to the tar payload installer
(image-installer) or the ostree installer (edge/iot-installer).
The only line that we add is the installation line in its own kickstart.
The user kickstart file is then added separately and it %includes our
own.

1. Kickstart tests now check if the pipeline serialization panic()s when
   unsupported options are combined.
2. When "extra" kickstart content is defined (user kickstart file), the
   pre-defined hardcoded kickstart bits aren't added to the checksum
   calculation.

Unattended + kickstart.contents is no longer allowed, so set unattended
to false.

Initialise kickstart customizations for an image with the common options
from the blueprint customizations.  The kickstart options are
initialised with Users, Groups, the Unattended and SudoNopasswd
installer options, and the custom kickstart content.  Other options
(Language, Keyboard, Timezone, and payload options) must be set
separately, since they aren't based solely on the blueprint
customizations and interact with other configs, like image config or the
ostree payload options.

Co-authored-by: Michael Vogt <[email protected]>

Co-authored-by: Michael Vogt <[email protected]>

Validate kickstart options in a Validate() function so unify option
compatibility handling.  The function is called from the kickstart.New()
initialiser, but we also call it before stage creation to make sure
everything is valid right before stage creation.

Co-authored-by: Michael Vogt <[email protected]>