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