BUGFIX: Companion packet timestamp mismatch trips replay protection

[entr0p1]

Initial login packet and REQ packets use the timestamp from the companion node's RTC. Most subsequent text packets using the timestamp from the companion node's mobile app. Drift between these timestamps can trip the replay protection and cause timeouts after login on the client side.

Fix changes this logic to send the node's RTC timestamp for TXT_TYPE_CLI_DATA messages instead of the timestamp from the app (matches the sendRequest() code logic).

Ideally we would use the same timestamp everywhere and this does work in my testing, however it breaks the "Heard repeats" in the mobile app (presumably because the timestamp is part of the packet hash and the heard packet doesn't match the one the app thinks was sent).

[liamcottle]

Regarding the heard repeats in the app, ideally we don't break that functionality.

This is probably the reason for these related issues linked below:

• Cannot remote admin Repeater from companion #983
• Remote Management via app unresponsive #1140

The app makes heavy use of sender timestamp and message content as a unique id for messages.
Mostly used for DM dedupe and heard repeats in the mobile app.

However for CLI commands, this change is probably OK, since the app doesn't care about the outgoing timestamp for CLI commands.

[entr0p1]

Hey mate!

Regarding the heard repeats in the app, ideally we don't break that functionality.
Yep, agreed. A fix isn't a fix if it breaks something else.

This is probably the reason for these related issues linked below:

* [Cannot remote admin Repeater from companion #983](https://github.com/meshcore-dev/MeshCore/issues/983)

* [Remote Management via app unresponsive #1140](https://github.com/meshcore-dev/MeshCore/issues/1140)

Highly likely. So far my tests have had significant improvements remotely managing repeaters. I discovered the issue by accident because I was sending commands that were timing out to a repeater I just so happened to be debugging at the time. Saw the debug log for replay protection on every packet I sent that was timing out.

The app makes heavy use of sender timestamp and message content as a unique id for messages. Mostly used for DM dedupe and heard repeats in the mobile app.

However for CLI commands, this change is probably OK, since the app doesn't care about the outgoing timestamp for CLI commands.

Yep, I found that out the hard way when I tested it for any text packet. Ended up narrowing the change to just the CMD packets which seems to not break anything in the app.

I do think for consistency sake it would be good to use the RTC from the node for all packets, if that can be coordinated in a way that the app knows its happening. Having said that I'm not sure if that's even technically possible or introduces an unreasonable level of complexity.