This is ridiculous how I've just reverted workaround of one thing only to find out another one needs fix. How do we even get a freaking message if we're set as offline? Did they even fix the problem CORRECTLY? Because I don't think so.
This is a very important optimization, as Steam might randomly fuck up and not apply default cutoff of last request (as stated in documentation). We have no interest of changes anyway, so we can skip all trades but active ones.
This event should work similar to Trading.OnNewTrade() event - we can call it many times, especially once per each game being added, and if we're adding many games through a bundle or app_license_request, we might quickly run into having 30+ badge parsing tasks queued, which doesn't make much sense considering that just 2 are sufficient for an update.
Correct it in a way that makes both me and Steam servers happy.
Gifts/Login limiter is actually working decent, because response is nearly instant and fast enough to not worry about it in long-run.
With inventory things are entirely different, as inventory fetching might take even a very long time, and while fetching one inventory, we might already run out of our delay and start fetching another one.
This is not a big functionality-wise, as it's nothing new for ASF to parse multiple inventories concurrently, but Steam Community actually counts number of requests, and our inventory function might ask for multiple pages during execution, which could quickly lead to a situation of 10+ ongoing inventory requests being sent concurrently for too many accounts at once, as we can't predict not only how long the request will be handled, but also how many sub-requests we will do across one.
This means that for optimal performance in terms of rate-limiting, we must limit ASF to one inventory request at a time, with mandatory InventoryLimiterDelay before asking for another one.
This can degrade performance of previously fast !loot requests on multiple accounts at once (especially with bigger inventories), but it will also decrease significantly a chance of getting rate-limited and requests failing.
Previously we calculated amounts (and therefore, differences) based on cards only, which means that user could earn some extra 'points' in our calculation for giving us many trash cards that we miss, and in exchange for that swap cards from some other game that would normally results in non-neutral difference on that game basis, but neutral+ in overall basis (that we operated on).
This would not cause any serious problem, because ASF ensures that trade is fair before calculating actual neutrality, but it could result in accepting a trade that is neutral+ only at first sight, and non-neutral+ when we take a closer look what we're actually swapping.
The logic was enhanced to handle differences on per-game basis now, and taking minimum in account, so all swaps on per-game basis have to be neutral+ now
