cloudapi: Add /distributions/{arch} to cloudapi

[bcl]

This pull request includes:

• [X] 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

[bcl]

I'm thinking I want to extend this to return more, so converting to draft for now.

[github-actions[bot]]

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]

I'm trying to remember why I included the actual repo data, and I think it was because we've had some questions about exactly what repos are being used for a build and no way to query that info. It's useful info, and easily available, so I included it.

As for the openapi layout, I couldn't figure out any other way to do it and have variable named keys. The reason for that is that it makes more sense to process the output using keys than it is to have to search through all the results for the distro+arch.

The output from this will be used with composer-cli in order to let the user explore what's available to use for the builds, so more detail is better.

[bcl]

In my case, a set of repositories would be a lot cleaner to consume rather than the list of repositories for each image type, but I'm not sure if this is desirable from the cli POV.

It's possible to have different repositories for each image type so you have to list them, even if they are normally identical. eg. gce has google specific repos added to it.

[mvo5]

We have a discussion about a similar feature in https://github.com/osbuild/images/pull/1167 and https://github.com/osbuild/images/pull/1173 for the CLI. The idea is very similar, show the available distros in a map like format but there the keys are slightly different. I would like to make sure we are aligned here (or at least talked about it).

For a user visible output distro->imgType->arch produces (arguably) nicer output, would a similar map style work for this API too or is there a deeper reason to use distro->arch->imgType? While its two different things I would like to align things when possible (also cc @schuellerf )

[bcl]

It makes more sense to me to have distro->arch->imageType for (at least) 2 reasons. Inputs to the compose/depsolve/search require distro and arch as part of the query, so in order to get the list of images you need to know distro and arch first. And the image types can add their own repositories, so each image type's repo list depends on knowing distro and arch first.

[schuellerf]

The structure I implemented was more from a user perspective where the possible image types for a given distro might be more interesting to visually see first, but I'm totally for consistency and I'll adjust the listing in images to match your structure ( being distro->arch->imageType ) it will still be readable I guess. Thanks @mvo5 for closing the loop and starting this discussion.