This is another great idea I thought about - ArchiHandler already receives all packets from Steam Network, so why bother checking if steam client is still alive if we can make use of the time last message arrived, and send request only when needed.
Extra points for performance benefits for accounts receiving lots of packets, so mainly primary ones with lots of friends/groups
Since HttpTimeout started affecting WCF timeout as well, and now I'm about to add yet another responsibility to this, this should be renamed to ConnectionTimeout.
Basically new HeartBeats() are cool, but user should have a direct way to configure the number of failed attempts allowed, as it can differ between stable and unstable networks, same like HttpTimeout.
This change apart from renaming HttpTimeout makes HeartBeats depend on it, allowing ConnectionTimeout / 10 failed attempts, and giving ConnectionTimeout / 30 minutes for steam servers to respond to out connection attempt. Both divisions are rounded up.
This should allow people with less unstable networks to get less clients being abandoned due to steam instability
This is because Steam network might literally die for several minutes WITHOUT our fault, so scheduling reconnect right away will not achieve anything. The way how it's right now seems perfect - we allow up to 5 minutes of HeartBeat() failures, then initiate force reconnect, and if that one fails for 2 minutes (total of 7 of downtime), we abandon the instance. This should be a really good balance between random Steam network quirks, and our broken SteamClient that might need to be re-created if things go seriously wrong