Add support for expiry date in ignore

[laurentb4]

Summary

This pull request adds support for an expires-after field to ignore rules, allowing users to specify a date after which an ignore rule will no longer apply. It includes validation, logic changes, and tests to ensure correct handling of the new field.

Motivation

Currently the .grype.yml file does does not support the inclusion of an expiry date for vulnerabilities that are intentionally ignored.

Changes

• Added a new expires-after field to the IgnoreRule struct, allowing users to set an expiration date for ignore rules. The rule will be ignored if the current date is after the specified date. [1] [2]
• Implemented helper functions parseExpiresAfter and isExpiresAfterInPast to parse and evaluate the expiration date, handling empty and malformed values gracefully.
• Updated the IgnoreRule.IgnoreMatch method to skip rules whose expiration date has passed.

Validation and Testing

• Added a Validate method to IgnoreRule to check for malformed expires-after values at config load time, providing early feedback to users.
• Extended and added new tests in ignore_test.go to cover various scenarios for the expires-after field, including valid, empty, past, future, and malformed dates.

Miscellaneous

• Updated documentation/comments and imports to reflect the new feature.

Type of change

• New feature (non-breaking change which adds functionality)

Checklist

• I have added unit tests that cover changed behavior
• I have tested my code in common scenarios and confirmed there are no regressions
• I have added comments to my code, particularly in hard-to-understand sections

[noqt]

I’m reviewing this for NOQT. I think this needs one safety fix before merge.

IgnoreRule.Validate() is added, but nothing in the production config/load path calls it. On the runtime path, isExpiresAfterInPast() catches a parse error and returns false, so a typo such as expires-after: 2026/12/31 silently leaves the ignore rule active indefinitely. That’s the opposite of the clear startup error promised by the new validation comment, and it’s risky for vulnerability suppressions.

Please wire this validation into config loading and add an end-to-end invalid-config test, or propagate the parse error through the application path. I checked exact head 55771f63b294e6ba2073177754d1622606b2a1de; it merges cleanly with current main. Hosted static analysis is also red on formatting, but the unreachable validation path is the blocker here.