Previous implementations had several problems when dealing with trade holds:
- User could've configured max trade hold duration to 0, and still accept trades with hold when he's the cause of it, this is unwanted
- There is virtually no way to ensure that the other party is willing to accept our trade hold even if we allow it, so expose that detail.
This precisely answers quite rather but not impossible situation of having a trade hold with ASF 2FA, e.g. due to moving authenticator, but we're also now ready for "perpetual" trade hold with ASF 2FA, in case it ever happened.
This way, we:
- Expose to other users our max trade hold duration preference
- Users validate both their own and listed user's trade hold, and if it exceeds either their own or user's limit, bot is not considered for matching
- It also resolves problem of accepting trade offers from other people when we're on trade hold ourselves
It might still make sense in order to:
a) Postpone timezoneoffset calculation until we actually get logged in, which gives machine more time for re-initialization
b) Refresh it in case our timezone changes, or DST gets enabled/disabled
My latest "research" resulted in learning that under the hood, Steam unix time seconds is bullet-proof not only for year 2038 but for uint range as well. While I do not expect to be alive by 2106, let alone ASF still being operative, it makes sense to base our time on the correct backend implementation regardless.
Small breaking change for people using `GetUnixTime()`.
