WIP fix: fixing rate limit client side issues. Reenabling async/await.

[SamuelBellomo]

adding wip for solution, focusing on query lobbies.
removing async wrapping needs, let's use async await properly
Real fix would be to come back to async await and simplify the error catching flow, catch the rate limit exception and only start rate limiting client side once we get that exception (instead of doing our own client side rate limit logic which isn't the same as the one applied on the server)

Description (*)

Related Pull Requests

Issue Number(s) (*)

Fixes issue(s):

Manual testing scenarios

1. ...
2. ...

Questions or comments

Contribution checklist

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• All automated tests passed successfully (all builds are green)

[pdeschain]

If we consider async/await (more linear flow) to be a better pattern than using callbacks - then yeah it's a great idea!

There is this nuance that we would need exception handling everywhere we invoke the lobby API - which adds a lot of boilerplate. That can be mitigated by having an async method that creates an internal task, awaits it and wraps it with some exception handling. Best of both worlds.

[SamuelBellomo]

@pdeschain is now working on this, let's close this prototype PR