Add multi-resolve functions to resolvers

[achilleas-k]

This PR adds convenience functions to the package, container, and ostree resolvers. This is an old branch I had sitting around that was following up from the original introduction of the manifestgen package. While working on Add proxy support to image-builder-cli (HMS-9645), I remembered that I wanted to move some of the conveniences of manifestgen into the resolver packages themselves and this is part of that.

Some background

The general flow of resolving content to generate a manifest is:

1. Instantiate manifest based on image type with customizations.
2. Get unresolved content descriptions (packages, containers, ostree commits) from the manifest, indexed by pipeline name.
3. Resolve each content type using an appropriate resolver, preserving the pipeline name indexing.
4. Serialize the manifest using the resolved content.

In (simplified) code, this looks like:

// Instantiate manifest
manifest := imgType.Manifest(blueprint, imageOptions, repos, rngSeed)

// Get unresolved content descriptions
packageSets := manifest.GetPackageSetChains()
containers := manifest.GetContainerSourceSpecs()
commits := manifest.GetOSTreeSourceSpecs()

// Resolve each content type
solver := depsolvednf.NewSolver(...)
depsolvedSets := make(map[string]depsolvednf.DepsolveResult)
for pipeline, packageSet := range packageSets {
	depsolvedSets[pipeline] = solver.Depsolve(packageSet)
}

// ... repeat for containers and ostree commits

serializedManifest := manifest.Serialize(depsolvedSets, resolvedContainers, resolvedCommits)

NOTE: This isn't entirely accurate code, but is simplified to emphasise the important parts (e.g. error return values are dropped).

The manifestgen.Generator.Generate function implements this flow, using the default configurations for each resolver and allows overriding them when needed.

New stuff

This PR only provides the ResolveAll() convenience which performs the iteration over the unresolved content indexed by the pipeline names. This moves some of the convenience provided by manifestgen.Generator.Generate() into the resolvers themselves, making them useful in cases where manifestgen isn't practical (e.g. in osbuild-composer where content is resolved on different workers).

Container resolvers

For a while now, we've had two container resolver implementations, an async one (the original) and a blocking resolver (introduced in #1176). There was a short discussion on that PR about the differences between the two. I summarised the consequences of switching to a blocking resolver in this comment. I'd like to prioritise consistency here over potential performance, but if we think we would benefit from parallel container resolution, we could go back to only having the async resolver but make its interface the same as the other resolvers (with Resolve() and ResolveAll()).

[achilleas-k]

Note that full (resolved) manifests have changed because the order of containers in the sources changes when using a different resolver. This isn't a functional change and doesn't affect the manifest ID.

[bcl]

Looks fine to me, agree with @lzap's comments.

[thozza]

LGTM.

I would not spend too much time optimizing or discussing SBOMs in the Solver, because at the end of the day, Solver won't be the place that will handle SBOMs in the future. All the SBOM code will be eventually removed from the Solver.

[thozza]

I would love us to move away from this pattern of constructing an instance just to modify it in the next step. Ideally moving towards the functional options pattern.

[achilleas-k]

Yeah the functional options you showed me the other day looks really nice.

[lzap]

I would really like us utilizing context more, while it is fine adding more fire-grained timeouts you could have an overall deadline as well. Also, contexts are great for logging contexts, granted, this is more relevant for the service (per request, per org) than CLI but it has its own use there as well.

Anyways, all is fine.

[bcl]

Looks good!