We don't need strict 1-request-at-a-time logic, just delay between consecutive ones. This doesn't change the logic dramatically, only starts counting delay the moment we send the request and not the moment we receive the response.
> The pattern is to take the basest class or interface possible for your arguments and return the most specific class or interface possible for your return types. This gives your callers the most flexibility in passing in types to your methods and the most opportunities to cast/reuse the return values.
Those SK2 calls are synchronous after all, and they might affect responsiveness negatively when a single bot is executing many of them.
This is once again not a problem of ASF, as here we can have like 1-2 concurrent API calls, but ArchiBoT suffered from this a lot.
In very rare scenario of starting from time X, calculating SteamTimeDifference of Y, then changing time from X to Z, old Y difference might no longer be accurate, which could lead to temporary failure of generating tokens/confirmations for given time.
Steam accepts tokens for quite a while (15 minutes from their time IIRC), so this would only hit us if we started from really huge time gap X, and not just normal typical small max 1-2 minutes updates.
Time to enforce some common file layout, as general mess started to annoying me. Sorry in advance for people using custom forks and having merge conflicts, this will help everybody in long-run
It seems that Valve actually accepts not one but several tokens generated close to the point of request being sent, so our 2FA code will be always valid for 1-2 more minutes after supposed timeout...
Thanks to that, we can guarantee some room for networking, but also make users more happy as they'll never get 2FA tokens no human is capable of entering in time
