Support regular re-enumeration of affected versions for existing records

[andrewpollock]

Problem statement:

Today, affected[].versions enumeration only occurs during the import of an OSV record.

#1987 has identified that it is conceivable that additional vulnerable versions may be released (for example, if the vulnerability was fixed in a backward-incompatible manner in a new major version branch) after the OSV record has been published (and imported by OSV.dev).

This means that it is possible for the OSV.dev API to return false negatives for new vulnerable versions released after the OSV record has been published and imported.

False negatives detract from OSV.dev's strategy to be a comprehensive, accurate and timely database of known vulnerabilities.

Proposed solution:

Periodically (interval TBD), reimport all of the records for a given source, causing the affected versions for each record to be re-enumerated, based on the facts available at that point in time.

How this reimport is triggered will vary between the different currently supported data sources:

GCS: Set ignore_last_import_time to true for the given source record in SourceRepository in Datastore Git: Set last_synced_hash to null for the given source record in SourceRepository in Datastore REST: Set ignore_last_import_time to true for the given source record in SourceRepository in Datastore

[andrewpollock]

Latest evolved thinking:

Do the moral equivalent of reimporting a daily rolling window of records, based on last modification time being greater than an age TBD.

Some of the definitional work that will happen as part of #2186 will influence the TBD.

[github-actions[bot]]

This issue has not had any activity for 60 days and will be automatically closed in two weeks