Fix Y2038 worker heartbeat overflow by migrating timestamps to i64

[dpol1]

What is the purpose of the change

Fixes the Y2038 heartbeat overflow issue. Worker heartbeat timestamps (time_secs) were carried as i32 seconds, which would overflow on 2038-01-19. This change migrates the timestamps to 64-bit values (i64) to prevent false timeouts and cluster failures post-2038. It also establishes the expected bounce-upgrade semantics for legacy heartbeats.

How was the change tested

• Added Y2038HeartbeatTest to ensure that 64-bit timestamps round-trip correctly through Thrift serialization.

• Verified that HeartbeatCache successfully parses and handles post-2038 heartbeats without flagging them as timed out.

• Tested schema backward-compatibility to ensure legacy i32 payloads fail validation gracefully during the bounce-upgrade window.

• Fixes [STORM-4116] Heartbeats mechanism is affected by Y2038 bug #7897

[rzo1]

Thanks for the PR. LGTM.

[reiabreu]

@dpol1 thanks for the submission.

What do you think about offering the possibility of heartbeat producers still sending 32 bits and Nimbus would ajust?
This could make the upgrade process smoother.

struct ClusterWorkerHeartbeat {
    1: optional i32 time_secs        // ← demoted to optional, kept for legacy readers
    5: required i64 time_secs_long   // ← new field at a new field ID
    ...
}

Then in the reader code:

long getTimeSecs() {
    if (isSet(TIME_SECS_LONG)) return time_secs_long;  // new writer
    return (long) time_secs;                            // legacy fallback, safe pre-2038
}

[dpol1]

@reiabreu yeah, optional-i32 + a new i64 field is the compat path I weighed before going in-place.

Two notes on the snippet: the new field needs to be optional, not required, or a legacy producer that only sets the old one fails Thrift's required-field check on the new reader and the fallback never runs. Also the read fallback only covers old worker → new Nimbus. A new worker writing only time_secs_long still won't deserialize on an old Nimbus, so a real rolling upgrade also needs writers setting both fields for a release, then dropping the i32 later.

I went in-place to avoid carrying two fields plus a cleanup release, and because these heartbeat structs don't have a rolling-upgrade contract today. A full restart avoids the mixed-version window completely — Nimbus times out on receipt time, so heartbeats recover within an interval once everything's upgraded.
If we want heartbeats to survive a rolling upgrade I'll switch to optional + dual-write and track the i32 removal as a follow-up. Otherwise I'd keep this and just call out the restart in the docs.

[reiabreu]

Thanks @dpol1 , it makes sense. Next version will be major where disruptions are expected. We just have to make this clear in the release notes.
Happy to merge this.