Ubuntu image publications aren't future proof against image behaviour forks

The correct way to query simplestreams for a particular thing is:

1. Filter for what you want that should narrow it down. This returns a list.

2. Choose from what you got back to get a single thing. This returns a single thing.

It is incorrect to assume that the output from step 1 is always a single item. This assumption can break in the future when we publish more things that match your filters.

The general form of this problem applies to the general domain of publishing images in a future-proof way, rather than something that only applies to simplestreams.

A hypothetical example:

Many users like that Ubuntu images are "brown", but there is an increasingly growing set of different users who would like Ubuntu images to be "green". Ubuntu decides to cater for this different set of users by now shipping two sets of Ubuntu images, both "brown" and "green".

We would expect to publish the metadata for this using a new key "color" whose value would be either "brown" or "green".

Existing programs that make the incorrect assumption above will immediately break, since they weren't filtering for "color". They used to get one image; now they get two.

A real example:

We hit this with Juju and the publication of HWE images.

Proposed solution:

To solve this problem, I propose that we publish a new key called "priority", which will be an unsigned integer between 0 and (2^32)-1 (inclusive).

Client programs should then implement step 2 above by sorting by priority from lowest to highest and then returning the first (lowest) entry.

Proposed implementation:

To implement this, just publish every thing with a priority of 1 (it doesn't actually matter). This allows clients to implement this behaviour now. We only need to worry about publishing different priorities as part of a future task when adding a new image dimension.