fix: preserve original telemetry timestamp on periodic resend

[tijn-hedgehog]

Summary

• Fixes periodic reporting overwriting the original telemetry timestamp with current wall-clock time in __periodical_reporting()
• Periodic resends now preserve the original source timestamp (report_strategy_data_record.get_ts()) so downstream consumers can detect stale data
• receivedTs in metadata still reflects when the gateway forwarded the data

Problem

When using ON_REPORT_PERIOD or ON_CHANGE_OR_REPORT_PERIOD strategies, the periodic reporting thread replaced the original telemetry timestamp with int(time() * 1000) before re-sending. This made stale data appear fresh in ThingsBoard. If a device stopped updating, the ts kept advancing every report period, breaking any staleness detection in dashboards, rule chains, or frontends.

Change

In report_strategy_service.py, __periodical_reporting():

# Before (overwrites timestamp):
current_ts = int(time() * 1000)
data_entry.add_to_telemetry(TelemetryEntry({key: value}, current_ts))
report_strategy_data_record.update_ts(current_ts)

# After (preserves original timestamp):
data_entry.add_to_telemetry(TelemetryEntry({key: value}, report_strategy_data_record.get_ts()))

The commented-out line that already existed for this purpose has been activated and the timestamp-overwriting code removed.

Test plan

• Configure a device with ON_CHANGE_OR_REPORT_PERIOD strategy (e.g. 60s report period)
• Send one telemetry value, then stop the device
• Verify ThingsBoard latest telemetry ts stays at the original value (does not advance every 60s)
• Verify receivedTs in metadata still updates on each resend
• Verify that when a new value arrives, ts updates correctly via filter_datapoint_and_cache
• Test with ON_REPORT_PERIOD strategy as well

Fixes #2119

[iamkaran]

Correct me if i am wrong but doesn't this defeat the purpose of ON_REPORT_PERIOD as it serves the purpose of maintaining connection activity by sending data periodically even if it is stale.
Its also mentioned in the docs:

The current_ts behavior is intentional: the periodic updates are heartbeats disguised as telemetry

[tijn-hedgehog]

If that's the case, then I propose a new reporting strategy that either sends data on change, or every reporting period (but preserves the timestamp so the user knows if it's stale).

In my customer dashboard, I want to show data updates periodically (eg, every 30s), but also instant updates when values have changed. When a device has gone stale, the current reporting strategy would keep sending the stale data as if it were fresh, misleading the customer. Currently, there is no (to my understanding, correct me if I'm wrong) report strategy that has this behavior.