[Breaking Change Request] Provide epoch timestamps in the FileStat notFound object

[sortie]

Intended change

The dummy object returned if FileStat.stat() and FileStat.statSync() fail now contains Unix epoch timestamps instead of null for the accessed, changed, and modified getters.

Rationale

These timestamps are always non-null if the API succeeds and the timestamps are meaningless when the API fails and returns the FileSystemEntityType.notFound type. This change makes the timestamps always non-null, which avoids all legitimate accesses needing a needless null check when Dart becomes null safe. This change is consistent with the mode and size getters that are initialized to non-null dummy values when the API fail.

Expected impact

Callers are supposed to handle if files doesn't exist or if the API fails for other reasons. The timestamp getters in question are meaningless if the API fails. Code that would break would be looking at these timestamps and acting differently if they are null, which is not the right way to use the API, as it should instead use the type getter to check for the FileSystemEntityType.notFound type. For that reason, reasonable code wouldn't break on this change and no breakage in particular is anticipated.

Steps for mitigation

Code that breaks should be updated to check for the FileSystemEntityType.notFound type.

Implementation

A proposed implementation of this breaking change: https://dart-review.googlesource.com/c/sdk/+/136585

cc @franklinyow @mit-mit @lrhn @athomas

[sortie]

A case was identified in package:watcher where it returns the modified time rather than checking for notFound and relied on non-existent files having a null modified time. It affects a single G3 test. The fix to check for notFound is trivial and backwards compatible.

[franklinyow]

cc @Hixie @matanlurey @dgrove @vsmenon for review and approval.

[Hixie]

fine by me

[matanlurey]

No input

[vsmenon]

lgtm

[franklinyow]

Approved