Refactor/bazaar data

[mkram17]

Depends on #83
Split up BazaarDataManager class
Converts incoming api objects into wrapper objects

TODO:
Convert user's orders into UserProductSummary's so they can be tracked in api data
Create version of BazaarDataUtil.findItemPriceOptional that ignore's users orders
Make MarketPrices.getPriceForPosition use the above method to find the price ignoring user's orders (#78)

[0xar-ds]

I have a very different implementation on my working tree which rather than to build a mutable Bazaar Reply, declares a Product Registry whereof api snapshot is one of the many sources ingested onto the hash map. I'll commit it to my fork in a sec so you can check which path you'd prefer

[0xar-ds]

I have a very different implementation on my working tree which rather than to build a mutable Bazaar Reply, declares a Product Registry whereof api snapshot is one of the many sources ingested onto the hash map. I'll commit it to my fork in a sec so you can check which path you'd prefer

https://github.com/0xar-ds/Bazaar-Utils/tree/refactor/bazaar-data-attempt

Every source is factored in currently, most consumers currently remain as a Stub as it is more a proof of concept. ItemPriceSourcesOverlay currently consumes the new API for showcase & debug.

• Order would be dropped in factor of TrackedPlayerOrder (or some other name we could give), whereas it'd be data object with no live subscriptions to no data whatsoever
• OrderInfo drops subscriptions as well, if live data access is needed, the registry should be queried at the right time. There were also events introduced for event-driven updates.

[0xar-ds]

lmk if you want me to get that tree/branch onto a more proper commit history on some branch of this repo, if you'd rather iterate/choose that

[mkram17]

@0xar-ds right now I am still looking it over... it's a giant update 😆 . Definitely we will use some of it if not all, but I would prefer if we could split it into smaller pr's where possible