cloudapi: Add architecture support to the optional Blueprint

[bcl]

If included it overrides the architecture in the compose image request.

This pull request includes:

• adequate testing for the new functionality or fixed issue
• adequate documentation informing people about the change such as
  • submit a PR for the READMEs listed here
  • submit a PR for the osbuild.org website repository if this PR changed any behavior not covered by the automatically updated READMEs

[github-actions]

This PR is stale because it has been open 30 days with no activity. Remove "Stale" label or comment or this will be closed in 7 days.

[bcl]

Changed this to address @thozza 's comments about arch handling in #4390

[thozza]

While this PR is OK from the implementation point of view, I don't like it from the architecture point of view...

I'm still not fully on board with the plan to add the architecture to the CloudAPI version of BP. The reason is that it duplicates the information already specified in the ImageRequest

osbuild-composer/internal/cloudapi/v2/openapi.v2.gen.go

Lines 833 to 856 in d531f62

	type ImageRequest struct {
	Architecture string `json:"architecture"`
	ImageType ImageTypes `json:"image_type"`
	Ostree *OSTree `json:"ostree,omitempty"`
	Repositories []Repository `json:"repositories"`
	// Size of image, in bytes. When set to 0 the image size is a minimum
	// defined by the image type.
	Size *uint64 `json:"size,omitempty"`
	// Options for a given upload destination.
	// This should really be oneOf but AWSS3UploadOptions is a subset of
	// AWSEC2UploadOptions. This means that all AWSEC2UploadOptions objects
	// are also valid AWSS3UploadOptionas objects which violates the oneOf
	// rules. Therefore, we have to use anyOf here but be aware that it isn't
	// possible to mix and match more schemas together.
	UploadOptions *UploadOptions `json:"upload_options,omitempty"`
	// The type and options for multiple upload targets. Each item defines
	// a separate upload destination with its own options. Multiple
	// different targets as well as multiple targets of the same kind are
	// supported.
	UploadTargets *[]UploadTarget `json:"upload_targets,omitempty"`
	}

Personally, I think that the fact that arch was added to the Weldr API BP version was a mistake. Instead, it should have been added to the ComposeRequest

osbuild-composer/internal/weldr/api.go

Lines 2417 to 2424 in d531f62

	type ComposeRequest struct {
	BlueprintName string `json:"blueprint_name"`
	ComposeType string `json:"compose_type"`
	Size uint64 `json:"size"`
	OSTree *ostree.ImageOptions `json:"ostree,omitempty"`
	Branch string `json:"branch"`
	Upload *uploadRequest `json:"upload"`
	}

struct for the Compose API call option when building an image for a specific BP.

Hardcoding the arch in the BP itself IMHO makes it less flexible to use for building various image types, and potentially for various arches. Architecture should be IMO treated in the same way as image type - you specify the BP name and when building the image, you pick the image type and an architecture.

I'm worried that we will make things more confusing and architecturally wrong if we add architecture to the BP in Cloud API.

I'd like to have a broader dicsussion and a consensus before we merge this.

[bcl]

All I'm trying to do here is make things consistent. Arch ALREADY exists in the blueprint, except that it wasn't added to cloudapi, so the current situation is that it's more confusing.
I don't think this is the place to discuss whether or not it should have been added, it is already there.
Also note that the arch is optional, so it only makes things less flexible if it has been set and that's under the control of the user. Maybe they have a blueprint they only want to use on a specific arch.