asyncio clean-up

[Julian-O]

There are a few opportunities to clean up the asyncio/threading behaviour.

1. If you are going to create a thread (e.g. for _run_socket), please provide a name parameter, e.g. name="pyTwitchAPI:_run_socket". This makes it easier debugging in larger systems.

2. EventSubWebsocket has its own Thread. This thread creates its own Event loop. I can't see how this is justified. It could be a task in the client's own event loop.

   That would get rid of the callback_loop parameter complexity. (That tripped me up, and caused in my code bug it took ages to track down.) It will require EventSubBase.start() to become asynchronous, which is an API change.

   This would address EventSub webhooks create own asyncio event loop and break on shutdown #350

3. There are several examples of busy loops - while loops with sleep() statements. Each can be replaced with the use of asyncio.Event - the busy waits are replaced with a wait on an Event. This is both more responsive and more efficient.

[Teekeks]

1. good point, will be added in the next update
2. its justified because it makes it possible to run this library along other, blocking code. The idea was that this allows integration with as many other projects as possible
   For callback_loop: some other projects are super picky in which event loop they are running in, so this lets you adjust that based on your project
3. good shout, will look into that as well for the next update or next major at the latest

[Teekeks]

To make some things more clear: I am not entirely happy how I am handling threating (among other things) and want to rework & streamline these aspects of the library for the next major release. But I know that I wont go away with treating entirely, I might make it optional though.

[EvieePy]

asyncio is intrinsically single-threaded. As #350 points out: each ES Webhook class is creating a new asyncio loop in a separate thread; this is also true for websockets. These subsequent loops aren't beneficial, and go against the fundamental design of asyncio.

If each loop is processing it's own set of tasks concurrently (notifications, heartbeats, sleeps) just to name a small few, all this thread (and every new asyncio-loop bound thread mutually) are doing is competing against each other (Python has a GIL and no multi-threaded async design as far as I'm aware for a released GIL on 3.14+) to process what could easily be done on the single event loop. asyncio is more than capable of processing a very large amount of IO bound tasks concurrently on a single loop.

There are limited use cases for spawning a thread in an asyncio environment, and if/when a library needs to, it should be clear to the user that this is what is happening. There should be basically 0 reason to ever spawn a new asyncio event loop in one of those threads either.

If the user needs to run their blocking code alongside the library code they should always be making that decision from an async first viewpoint.

[Teekeks]

After some more looking though the projects history, some of the cases its used in and what I actually want to achieve in v5, it seems like going away with threads and fully relying on asyncio is probably the right step forward.

But again, this will be something to be added in v5, not v4 so it will take quite some time till its ready.