Refactor @run_async

[Bibo-Joshi]

• Deprecates the @run_async decorator
• Instead adds kwargs update and error_handler to DP.run_async() to allow proper error handling
• Allows to specify that a callback should be run asynchronously via DP.add_handler/DP.add_error_handler

One problem: In the new setting it's currently not possible to make the handlers of a ConversationHandler be run asynchronously. Possible solutions:

• When adding a CH via DP.add_handler(CH, run_asyn=True) make all handlers of the Conversation async
• Set the run_async flag as parameter for Handler instead of as parameter for DP.add_handler
• Somehow build an option for that into CH

Wanted to have that clarified before going for the tests, so WIP.

When ready, closes #682 and superseeds/closes #785

[Bibo-Joshi]

I made two additional changes to Dispatcher.update_persistence:

1. Use a lock to ensure that the method is not called twice simultanuously
2. convert dispatcher.user/chat_data.keys() to lists to prevent errors like this. That particular one was probably caused by JobQueue calling Dispatcher.update_persistence while an entry was added to dispatcher.user_data, but similar situations can probably also arise when calling Dispatcher.update_persistence from the async threads. We don't acutally have to worry about the new entry not being persisted, as update_persistence() will be called for the update that lead to the new entry anyway.

[GauthamramRavichandran]

Could this async be added to job callback as well? I'm using @run_async decorator to run jobs in parallel for now

[Bibo-Joshi]

@GauthamramRavichandran Please have a look at this comment :)

[Bibo-Joshi]

As discussed, I restructured a bit. Let me try to summarize:

• The error_handler parameter for run_async was basically there to avoid infinite loops coming from asynchronously run functions error handlers
• instead, now there is just a parameter async_error_handling. When False, no async error_handler will be called*
• but we don't even handle sync errors raised by error handlers. So now there is just a parameter error_handling for run_async. When False, the error will just be logged.
• We only have one set of error handlers, namely those registered with add_error_handler
• new parameter async_params for CallbackContext so that the params for custom async functions can be accessed from the error handler

[tsnoam]

Great work