build: be more selective about specifying the default OS

[nalind]

What type of PR is this?

/kind failing-test

What this PR does / why we need it:

Only add the default OS to a build target platform struct if the architecture was specified without one, so that the pull logic in containers/common doesn't override our pull policy when it doesn't need to.

How to verify it

New integration test!

Which issue(s) this PR fixes:

This should restore the ability to use --pull=missing, which was inadvertently broken in #5478.

Special notes for your reviewer:

Does this PR introduce a user-facing change?

None

[flouthoc]

LGTM

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: flouthoc, nalind

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [flouthoc,nalind]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[rhatdan]

/lgtm

[mtrmac]

I realize we are in urgent-hot-fix mode, and I don’t want to interfere with that.

Afterwards, dare I ask for some cleanups?

• It’s absolutely unclear to me how setting platform.OS is supposed to result in setting TARGETARCH. Why are the two related? I don’t understand how Setting --arch should set the TARGETARCH build arg #5478 fixes its subject. Either the fix should be something completely different, or the relationship should have been recorded in a comment warning about the non-obvious relationship; or maybe the PR is doing something else than it claims to.
• AFAICT internalUtil.NormalizePlatform == libimage/platform.Normalize always returns "" for an "" input (i.e. it only normalizes non-empty inputs). So the added check could be moved below the NormalizePlatform call; that would make the meaning of the platform.OS != "" condition clearer.
• Looking at the code in buildDockerfilesOnce setting the TARGET* variables, that assumes that OSChoice/ArchitectureChoice/VariantChoice are always set. The code after Setting --arch should set the TARGETARCH build arg #5478, at best, changes that for OSChoice, but not for the other two. It seems to me that the right fix would be either to change buildDockerfilesOnce to not make that assumption, or to reach the way all the way down inside libimage/plaform to centralize the meaning of "" to be runtime.GO*; it certainly would not do to have that assumption, in the worst case, implemented in libimage for variants, in BuildDockerfiles for OS, and in buildDockerfilesOnce for arch.
• Please clarify the semantics of BuildOptions.{Architecture,OS}, and then update users. stageExecutor.commit seems to consider "" valid, but the LogSplitByPlatform determination of logFile seems not to expect that. AFAICS one of the two is wrong.
• BuildOptions.SystemContext is documented to hold credentials; if it holds the platform as well, that documentation should be updated.
• I’d love to see the code turning options.Platforms[*] into platformOptions.{OS,Architecture,SystemContext} (or however the information ends up being represented) split into a separate function with a unit test.

[TomSweeneyRedHat]

@nalind all kinds of test unhappiness and a rebase is wanted.