Add TXG timestamp database

[oshogbo]

Motivation and Context

This feature enables tracking of when TXGs are committed to disk, providing an estimated timestamp for each TXG.

With this information, it becomes possible to perform scrubs based on specific date ranges, improving the granularity of data management and recovery operations.

Description

To achieve this, we implemented a round-robin database that keeps track of time. We separate the tracking into minutes, days, and years. We believe this provides the best resolution for time management. This feature does not track the exact time of each transaction group (txg) but provides an estimate. The txg database can also be used in other scenarios where mapping dates to transaction groups is required.

How Has This Been Tested?

• Create pool
• write data
• wait some time
• write data
• wait some time
• try to scrub different times

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[amotin]

It crashes on VERIFY(!dmu_objset_is_dirty(dp->dp_meta_objset, txg)).

[amotin]

This reminds me we recently added ddp_class_start into the new dedup table entries format to be able to prune DDT based on time. I wonder if we could save some space would we have this mechanism back then.

[amotin]

@oshogbo zpool_scrub/zpool_scrub_date_range_001 test failed on almalinux8.

[oshogbo]

I think the problem with almalinux8 is finally solved. It was caused by using /dev/random instead of /dev/urandom, which resulted in empty files. The zinject tool injects a data error, but because there was no data, the second file wasn't detected as corrupted.

I also found an issue with timezone calculation, which has now been fixed.

Additionally, I changed the way we select the final time. Since we have three different groups of timestamps, we can't simply select the smallest TXG as the start date - doing so would always pick the one from the "lowest frequency group" (monthly). So instead, we still floor each group, but we now select the time that is closest overall. Hope that makes sense.

[behlendorf]

It looks like we had some unexpected failures in the centos-stream builders as well which need to be looked at:

https://github.com/openzfs/zfs/actions/runs/16548417061/job/46985751681?pr=16853

 Tests with results other than PASS that are unexpected:
    FAIL cli_root/zpool_scrub/zpool_scrub_date_range_001 (expected PASS)