Inventory fetching through CM

[ezhevita]

Checklist

• I read and understood the Contributing Guidelines.
• This is not a duplicate of an existing merge request.
• I believe this falls into the scope of the project and should be part of the built-in functionality.
• My code follows the code style of this project.
• I have added tests to cover my changes, wherever they are necessary.
• All new and existing tests pass.

Changes

New functionality

None

Changed functionality

Inventory fetching now works using CM requests instead of web API, there are no rate-limits and it allows loading even 82k+ inventories in about 11 seconds.

Removed functionality

Fetching foreign inventories is no longer possible, however it wasn’t used in ASF anyway and it is rate-limited to hell ¯\_(ツ)_/¯

Additional info

This code was in production for about a year so it works pretty stable and Steam didn’t break anything in this time period. Also current implementation of AdditionalProperties is pretty awkward so any suggestions to improve it are welcome.

[JustArchi]

After brief evaluation, good stuff 👍

I'd use this opportunity to refactor and reuse components as much as possible instead of bringing up our own ones:

• Since this is CM call, you most likely have proto body already - we should use it if possible instead of bringing up our own re-implementations and on top of it exposing additional properties in non-unified way.
• We can still utilize general composition/wrapper pattern, for example, we can initialize our own class taking protobuf data in constructor, have a readonly field for keeping it, then adding appropriate getters/setters we care about reaching it. Moreover, the field can be public which would allow plugin creators to extract other information from it without our hard mappings.
• In regards to description, I was thinking about it for a while, and it might make sense to just have description as such field/property inside item, with maybe additional helper properties like uint RealAppID => Description.RealAppID. I don't like our current code that does a lot of back and forth parsing/setting.
• I'd like to keep method in AWH, because it can still be used for fetching other inventories than our own one, EVEN if heavily limited. We can make new classes described above compatible with it - use protobuf member as "backing" field for data, mark it as [JsonIgnore], then add helper properties with getter and setters, annotate them as json-compatible, and add logic for each property to get/set appropriate value in underlying backing protobuf field. This way you'd have one "superclass" for asset and description, that'd still be compatible with both, being constructed from CM response (you pass received protobuf as constructor), as well as AWH json response (json serializer creates it, then calls setters for each helper property, effectively manipulating underlying protobuf without even realizing).

Does that make sense to you? If yes, we don't need to worry about breaking changes much (for plugin creators), as such refactor is totally justified for future of the program.

[JustArchi]

As I wrote on Discord, the current direction this PR is going is superb, we only need to fix all pending warnings and other errors - feel free to request re-review after that happens and I'll be happy to merge it in if no outstanding problems are found.

[JustArchi]

Mostly misc stuff, everything else LGTM

[JustArchi]

Thanks a lot! 🏆