Incorporate the platforms JSON file into the container,
 as it is essential for our OSBuild requirements.

Signed-off-by: Renata Ravanelli <[email protected]>
(cherry picked from commit 410cf90)

Addition of platforms.json was originally added in 410cf90. Here
we make a few improvements:

- We don't need to export platforms_json has that wasn't being done
  before 410cf90.
- We need to only create a file that gets included in the OSTree
  or Container if there are platforms.yaml entries for that arch.
  So we modify it here to create "${platforms_json}.all" first and
  only write to "${platforms_json}" inside the if condition. This
  makes it so s390x won't get a platforms.json file, which is what
  we want.
- We need to create these files in directories scoped to individual
  processes. i.e. if `cosa buildextend-metal` and `cosa buildextend-metal4k`
  run at the same time creating these files shouldn't race.

(cherry picked from commit 509f470)

It doesn't work properly against these rhcos- branches anyway. Let's
just limit the testing to building the container and running check
and unittest tests.

(cherry picked from commit 511a61d)

The version of OSBuild in the F39 repos is newer now and the patches
don't apply any more. In the main branch we've solved this by pinning
OSBuild on specific versions. For 4.15 we don't even need to do
the patching because we aren't building using OSBuild in the pipeline
for 4.15.

Attempting to override the http scheme for each request is not working
for every request type. Let's set the client config scheme to HTTPS by default.
Move away from `NewClientWithAccessKey` and instead create an access key
separately and then use `NewClientWithOptions` to create the client with a
custom config using "HTTPS" for the scheme.
Also remove the scheme override for each request.

This reverts commit 0b659af.

That was meant to be a temporary measure but lingered for a while. As
mentioned there, ideally, we'd build both, but if we only build one, let
it be RHCOS.

There is a history of failure copying images to other regions on
aliyun. Upstream code that calls the CopyImage code more than once
will get a DuplicateImage error when an image with the same name
already exists. Let's check to see if the image name exists in the
region before attempting to copy the image to the region and return
early if it already exists.

This is very close to `cosa supermin-shell` but instead expects a
command to run inside the supermin VM. Essentially, it's a very thin
wrapper around the `runvm` family of functions in `cmdlib.sh`.

By having it be a dedicated function, it becomes like a utility command
to have easy access to a privileged environment, with the working dir
automatically mounted in, podman remote proxying, etc... Note also this
*does not* require a cosa workdir.

The podman machine OS pipeline will be using this temporarily.

In a cosa workdir, that dir always exists in both privileged and
unprivileged paths.

Prep for a new command that'll use this code outside a cosa workdir
where to be nice we don't want to just randomly create a cache dir even
when no caching is required.

This is a follow-up to 79b15c8 ("cmdlib.sh: go back to using `tail -F`
for command output") which was subsequently reverted.

To summarize, it seems like in QEMU v8.2 (in f40), the guest sometimes
would hang when writing over virtio-serial if the device is hooked up to
the QEMU's stdio.

In testing, removing the `<&-` hack to close QEMU's stdin fixed it for
CoreOS CI but not Prow:

#3785 (comment)

I think I've narrowed it down to CoreOS CI (i.e. Jenkins) allocating a
tty and Prow not. When stdin is not a tty, QEMU would immediately gets
EOF if it tries to read anything. I'm not sure exactly what happens, but
I think the virtio-serial hang is linked to this (even though there's no
userspace code in the guest trying to read from the virtio-serial port).

Work around this by explicitly feeding `/dev/zero` to QEMU's stdin.

(cherry picked from commit bb60451)

`qemu-secex` is the artifact name used in meta.json and elsewhere
so let's support calling it that way like we do for other artifacts.

The `cmd-buildextend-secex` symlink is left in place for backwards
compatibilty.

(cherry picked from commit 85931e4)

Possibly something changed on the AWS side, but we're seeing what looks
like `SnapshotTaskDetail` structs coming back with some of the fields
empty. Gracefully handle this case.

Ensure that setting up a LUKS device with FIPS incompatible algorithms
will fail when FIPS mode is enabled.

Only run this on QEMU as it should behave the same way on all platforms.