improve logging in lock generation

[cbgbt]

Description of changes:
I had a twoliter update fail and it was difficult to determine why, so I've added additional logging to lockfile generation. I've also done some minor refactoring of the Kit metadata extraction code that threw the error in question.

This (potentially controversially) adds a dependency on the tracing crate. Here's why I like this dependency:

• Makes it easy to emit trace-level logs for each function call using the instrument macro
• Makes it easy to add context to log messages with helpful variable values
• Integrates with the log crate for output, or optionally allows more complex IO via the subscriber concept.

Here's an example:

[2024-07-28T03:18:49Z INFO  twoliter::lock] Resolving project references to create lock file
[2024-07-28T03:18:50Z ERROR twoliter::lock] Mismatched kit metadata in manifest
list canonical_metadata=<ImageMetadata(decoded) [ImageMetadata { name: "bottlerocket-core-kit", version: Version { major: 2, minor: 0, patch: 0 }, sdk: Image {
name: ValidIdentifier("thar-be-beta-sdk"), version: Version { major: 0, minor: 43, patch: 0 }, vendor: ValidIdentifier("bottlerocket-new") }, kits: [] }]> kit_metadata=<ImageMetadata(decoded) [ImageMetadata { name: "bottlerocket-core-kit",
version: Version { major: 2, minor: 0, patch: 0 }, sdk: Image { name: ValidIdentifier("thar-be-beta-sdk"), version: Version { major: 0, minor: 43, patch: 0 }, vendor: ValidIdentifier("bottlerocket") }, kits: [] }]>
Error: Metadata does not match between images in manifest list

Testing done:

• make build succeeds
• twoliter update emits helpful logs on failure
• twoliter update succeeds within existing workspaces

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

[bcressey]

Is the Docker image tool going to be robust for parallel invocations?

[cbgbt]

It seems to support it (based on my own testing and a lack of warnings found online), but since a pull can result in many parallel layer pulls, 8 is probably too generous of a limit.

I also don't know if the parallel pulls collapse common layers into a single request (I'm guessing not), but the images won't really have layers in common anyways, since they are different architectures.

My real goal here was to separate the kit metadata fetch from the check that the metadata was consistent across images as a clarity change. The parallelism was added as a bonus. I wouldn't be opposed to removing it. For now, I'll just lower it.

[cbgbt]

^ Remove concurrent image procedures. Potential instability is probably not worth the potential performance improvement.

[cbgbt]

^ Force push to rebase