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.