Make file time available for dnf plugins

[thebearup]

Makes the "file" time for a given package available for plugin use, to enable virtual snapshots (safe upgrades) based on the time a file was published.

[thebearup]

Context for this pull request: one feature that many users desire is "safe updates." They want to lock into a timestamp at which all updates in a repo have a been tested to be safe/compatible. The Debian ecosystem handles this with repo snapshots, which are cumbersome (an entire copy of the directory structure, which is not very cache-efficient). Since rpm repos have filetime embedded in the repo index, this offers an elegant solution: the client can filter out all packages whose timestamps are greater than the selected timestamp.
From prior investigation, it appears this functionality would best be offered as a dnf plugin vs built-in dnf functionality. However, file time is not exposed to dnf plugins, and build time is a less reliable indicator here (as a package could be built days or weeks ahead of time).
Hence this pull request: expose file time to dnf plugins, so that a plugin can use it for package selection.

[ddstreet]

They want to lock into a timestamp at which all updates in a repo have a been tested to be safe/compatible

It seems like this could easily result in a broken system, if the chosen timestamp happens to fall in between a package's rpm and one of its version-locked dependencies, for example if we want to install "foo-1.2.3" and that rpm requires "libfoo = 1.2.3", but the chosen repo timestamp is after the "foo-1.2.3" rpm's file timestamp and before the "libfoo" rpm's file timestamp, then installing "foo-1.2.3" won't be possible because of missing dependencies.

I believe that is currently not an issue since the repo metadata is updated in a consistent way (i.e. I assume that both the "foo" and "libfoo" packages are available in the repo directory location before updating the repo metadata to announce that they are available), but using a timestamp like this loses the atomicity of repo metadata updates.

Have you considered that situation and/or do you have a working PoC for the timestamped-dnf-update you are using this for?

[jslobodzian]

It seems like this could easily result in a broken system, if the chosen timestamp happens to fall in between a package's rpm and one of its version-locked dependencies, for example if we want to install "foo-1.2.3" and that rpm requires "libfoo = 1.2.3", but the chosen repo timestamp is after the "foo-1.2.3" rpm's file timestamp and before the "libfoo" rpm's file timestamp, then installing "foo-1.2.3" won't be possible because of missing dependencies.

From the greater system pov, that is a possibility, but it's a little out of scope for this. The goal with this pr is to simply expose the filesystem timestamp. How that is used is up to the caller.

[ddstreet]

it's a little out of scope for this.
i suppose that is true