[feature] Send server time in initial connect response.

[BusterNeece]

The type of data I'm sending for my application involves a lot of relative timestamps that are used to determine how much time has elapsed in a track or is remaining for display. If we compare this against the user's local time as one might for rough "x minutes ago" type comparisons, the drift between users' clocks and the server clock is very apparent and causes all kinds of problems.

Currently, to remedy this I send over the server's current UNIX timestamp as part of the data push. Previously, I was doing this with a standalone global:time channel, but realized this could just as easily be incorporated into the regular data feeds, so I switched over to putting it there instead.

However, with the discussion of adding support for what is basically "cached mode", there's the possibility that Centrifugo could be pushing data that isn't current to approximately the second it's being sent out. This means if we relied exclusively on the cached data feed, our users would have the wrong server timestamp to compare things against. This would mean we'd have to roundtrip to the backend just to get the timestamp anyway, which would remove almost all the possible performance boosts of cached mode.

The easy solution to this, for us, would be to include the server timestamp (in any form, really, though since "epoch" already uses the UNIX timestamp as an int, it might as well be in that format for consistency) in the initial "connect" push somewhere. It doesn't really matter where, as long as it's there. Once we have that initial data, we can take care of synchronization down the line.

[FZambia]

Hello @BusterNeece,

Current plan is to add server_time as Unix milliseconds in the connect reply (connect push in unidirectional case). I think it should be optional. Will require the following steps:

1. Add field to protocol
2. Start returning it when configured, sth like client_connect_include_server_time option
3. Add it to connected event context in bidirectional SDKs

[BusterNeece]

@FZambia That would work perfectly for me. Thank you for your continued hard work!