osbuildmonitor: add new package to monitor osbuild output

[mvo5]

This commit adds support for scanning/parsing the jsonseq based
monitoring that osbuild provides. This is useful for machine
readable status reporting and progress information for e.g.
bootc-image-builder.

The API consists of a new osbuild.Status struct that contains
parsed details about the osbuild status/progress and a scanner
that can scan a stream of osbuild jsonseq based progress and
emit osbuild.Status structs.

Note that the status is broadly of two categories:

1. information amining at a user interface (like
   status.Message or status.Progress)
2. low-level details for logging/error reporting (like
   status.Trace and status.Timestamp

Note that error handline a bit weak right now. The consumer
of the API will not get an error via the monitor currently
but only know that something went wrong from osbuild exiting
and then the consumer needs to reconstruct the error log from
the trace messages. This is not a show-stopper but we could
improve this by merging osbuild/osbuild#1831
and adding Result to the statusJSON and Status (but this
needs more thinking and probably best done in followups).

See https://github.com/osbuild/bootc-image-builder/compare/main...mvo5:progress3?expand=1 how this will be used.

Note that the provided information is intentionally small right now,
we will need to go over the osbuild implementation and see if we
should improve things here too (c.f. 1831) but it's a good starting
point I think.

The two main use-cases this should cover right now:

1. Allow to hide all low-level osbuild output when run on the terminal and show only progress information (e.g. bib and image-builder-cli)
2. Write a log file from "Trace" lines so that the full build can be easily reviewed or in case of errors reported

[achilleas-k]

Some small comments from a quick review.

[achilleas-k]

[draft until I have integrated this into either ibuilder(image-builder-cli)/bootc-image-builder) to show that it has no gaps, but wanted to show it here for early feedback]

Why not add support for it directly here in osbuild.RunOSBuild?

Note that this function is used by osbuild-composer, so changing it will need changes when it's integrated there, but that is a central point to add support for this I think and it can then be immediately tested with cmd/build.

[achilleas-k]

Also, since all interfaces to osbuild live in pkg/osbuild/ perhaps we could move this package there as well? Maybe as a subpackage (pkg/osbuild/monitor/) if you think that's cleaner.

[mvo5]

Also, since all interfaces to osbuild live in pkg/osbuild/ perhaps we could move this package there as well? Maybe as a subpackage (pkg/osbuild/monitor/) if you think that's cleaner.

I like it and it fits well into osbuild - my only small worry would be that the go doc pkg/osbuild output is already very big as it contains all he bindings to the stages. But happy to move it there.

As for the integration with RunOSBuild that is also planned of course but the final shape is not clear in my head, the (simplisitic) way to drive it right now is https://github.com/osbuild/bootc-image-builder/pull/525/files#diff-930ca2eb460ee83e152bc1133ce98074bc7b26bc23a40e66cccb1ffdc5406140R158 but I think it woudl evolve into a "RunOsbuildWithOpts" or something and then a Options struct with keyword like args, the existing interface to run osbuild can probably reduced to take less args with that.

[achilleas-k]

I like it and it fits well into osbuild - my only small worry would be that the go doc pkg/osbuild output is already very big as it contains all he bindings to the stages. But happy to move it there.

I've wondered once or twice if it would be cleaner for each stage to be its own subpackage, but I think that's a bit much. Maybe stages, sources, inputs, mounts could be separate though? A decision for another time.

[achilleas-k]

Ship it!