Introduce ext.dota2 - Dota 2 Game Coordinator extension

[Aluerie]

🐸 Summary

This PR introduces ext.dota2 extension.

🖍️ TODO

🐍 Migrate ValvePython/dota2 implemented methods.

• 👨‍💼Player
  • request_profile
  • request_gc_profile (disabled by valve?)
  • request_profile_card
  • request_player_stats
  • request_player_info (disabled by valve?)
  • request_conduct_scorecard (behavior score system was revamped though)
  • request_hero_standings
• ⚽Match
  • request_matchmaking_stats
  • request_match_details
  • request_matches
  • request_matches_minimal
  • request_top_source_tv_games
  • request_player_match_history
• 🥳Party
  Sorry, I'm not interested in implementing this atm. So this PR won't cover it. I don't see much point. Why would I want a bot to join parties. And Tournament Orgs already have all the tools for their automated lobby/party invites.
• 🦞 Lobby
  Same^
• 🗣️Chat
  Same^
• 🤝Shared Objects
  • Not sure what exact information those caches contain but sounds interesting to investigate.
• 🛠️Utils
  These should reside on Match/PartialMatch
  • replay_url
  • replay_url_from_match
  • metadata_url
  • metadata_url_from_match

💡Current Thoughts

Might edit this one a lot, maybe should write it in my todo app instead of here.

• Is there a potential concurency problem for top source? like responses aren't unique enough. for example, live_top_matches first check is start_game=0 but it will be satisfied automatically iif let's say responses from other two methods happen at the same time.
• Maybe PartialMatch class - does it make sense even? So LiveMatch would subclass it and it could be fetched into real Match after it's over.
• My favourite Social Feed message proto
• Implement something like Current Logged In User
• Add Rank request and behavior score requests to it ^
• look at todo comments in the code
• Is there cache or message for Dota+ hero level?
• Write some example

🔚 Checklist

• If code changes were made then they have been tested.
  • I have updated the documentation to reflect the changes. (a bit?)
• This PR fixes an issue.
• This PR adds something new (e.g. new method or parameters).
• This PR is a breaking change (e.g. methods or parameters removed/renamed)
• This PR is not a code change (e.g. documentation, README, ...)

[Gobot1234]

Thank you so much for this!

These don't need to be included, they are for steam non-sense.

Also if you wouldn't mind please could you clean up the enum names to remove underscores and normalise them to be PascalCase.

Finally could you add a very barebones test to the tests directory just to ensure that the client is importable

[Aluerie]

Thanks for the feedback!

Last time I had similar conversation (with Riot Games API wrapper developers) they actually had the opposite opinion - that it's better for both library devs and end-user to just follow "bad naming/practices/models" from the original devs instead of rethinking/over-cooking. The proto-models are here and kinda working - why not just give easy access to them, they aren't so bad, honestly.

Maybe affected by those, I just thought

• to compile all protos
• to list all known emsg-response pairs
• to have easy kwargs->proto interface and let the user do whatever with returned responses.
• only then implement helper methods which would modelize the responses.

But I definitely see your points/philosophy. Sorry that I was too linear. Let's modelize this stuff right away then. So... I've done a total overhaul of the PR (maybe I should resubmit it for cleaner commit history?). This is what I changed:

• In practice, this top source proto message has very little keyword combinations that work and make sense. Thus, I reimplemented this into 3 separate methods.
• I also implemented some models to wrap responses and its fields.
• deleted all unused enums and proto messages -> naming and steam nonsense problems are gone.
• intial test file.
• moved EMsg to enums.py in root of the extension (kinda like yours).
• renamed some files to feel more pythonic and less valve-gibbersih prefixes (kinda like yours).

[Gobot1234]

Overall looks very good, nearly there.

Last time I had similar conversation (with Riot Games API wrapper developers) they actually had the opposite opinion - that it's better for both library devs and end-user to just follow "bad naming/practices/models" from the original devs instead of rethinking/over-cooking

I wouldn't disagree if the names were consistent at the very least but with steam they aren't

[Gobot1234]

This should all be performed in state and should raise a WSException