Add selected parts of .BUILDINFO to JSON metadata

Use case

Currently it is not very easy to find out which packages in the repositories have been built with a certain version of a package. This information can be useful e.g. when rebuilds for a newer version of the dependency are necessary, in order to find out which packages were built against the old version and need to be rebuilt.

Specifically for soname bumps, we currently use sogrep, which keeps its own internal database for all packages in the repos. However, this approach is limit to explicit soname bumps, which not all upstream projects perform reliably. sogrep also does not help in cases like "strip command of binutils 2.36 changes ownership in fakeroot 1.25.3" where packages with a certain version of a package in the build environment (not distinguishable by soname) need to be rebuilt.

Proposed solution

A possible solution would be recording information about the environment in which a package was built in the JSON metadata. This would make searching for packages that were built with a certain version of a dependency much easier.

In comparison, for the security rebuild due to wrong file ownership mentioned above, we had to go through all package files on the tier 0 mirror and extract and parse the .BUILDINFO using a custom Python script instead.

Suggested approach

.BUILDINFO contains all packages that are installed in the build environment as well as their versions. Record this information in the same way that we already want to keep track of (explicitly specified) dependencies and make dependencies, but including their version numbers.

Other information recorded in .BUILDINFO that might be interesting to include in the JSON metadata:

• buildtool/buildtoolver, new in pacman 6, in case something ever goes wrong with a devtools release (e.g. insecure compiler flags) and we need to rebuild all packages built with that particular devtools version.
• pkgbuild_sha256sum, to make it easier to find the PKGBUILD associated with a particular version (might not be necessary if the PKGBUILD is stored together with the JSON metadata in the repository though).

Most other fields in .BUILDINFO duplicate information available in the pacman database that we already want to store anyway. buildenv and options are an exception to this, but I cannot see a possible use case for recording these at the moment.

Limitation

Even with this information recorded in the JSON metadata, finding all packages that require a rebuild might take some time because you would have to search through thousands of text files. It might be interesting to keep all of this information in a single database to make querying it easier, however this is out of scope for this issue.