Revisit public image handling

[markylaing]

#14260 will add support for fetching images in all projects. This has led to a discussion around the purpose of public images that are not in the default project.

If I make project foo, then create an image and make it public, it's not accessible to an untrusted caller unless they know that project foo exists. Additionally, how could the untrusted caller resolve any aliases related to the image?

Similarly, if I'm running a nested LXD all image requests over devlxd are using the default project. So I can't expose an image to a nested LXD in a non-default project by making it public.

Generally I think this all needs work. Priority wise this depends on whether people actually use the feature (my feeling is probably not very much). For nesting it already works well because cached images are always placed in the default project.

As an idea, since image fingerprints are unlikely to collide we could present a view of public images from all projects. For example, if the caller is not authenticated GET /1.0/images would return all public images regardless of project. If the caller is authenticated, it will return all public images and all images in the default project that are private (providing they have permission to view them). However this would become tricky if the caller needs to resolve the image from an alias, as aliases are project specific and likely to collide.

[tomponline]

For nesting it already works well because cached images are always placed in the default project.

Is that true? What about images downloaded into a project with features.images=true?