Switch to long running tasks for the multiplexer

[bdraco]

Testing TODO:

• implement back pressure Implement pause and resume requests for a channel #353

• download multi gig file

Known issues

• fix https://github.com/NabuCasa/snitun/pull/344/files#r1950170492

• server sni listener has the same design which is also likely to create many tasks on server side

  snitun/snitun/server/listener_sni.py

  Line 139 in da7a663

  from_proxy = self._loop.create_task(reader.read(4096))

• This reduced the amount of tasks being created while accessing the UI by ~96%

• RangedTimeout reduced the number of created TimerHandles by ~94% while accessing the UI by

Some considerations

• The timeout is now enforced for the read/write of the message so if it takes more than timeout to read or write the message it will timeout. Thats probably not a problem since the ping/pongs would be blocked and fail the connction anyways.

While these changes are designed for the client side, this combination of these changes is expected significantly increase the number of active connections a serve can handle at one time.

Instead of creating many small tasks, create two long running ones for the reader/writer to avoid flooding the event loop with tasks when the connection is generating many packets.

This is still a bit of a WIP, but should be deferred until after a release with #303 so they get separate release cycles

[bdraco]

We could probably have a single low res TimerHandle that resets on each loop and has a 10s leeway to re-arm. So we ensure we cancel both read/write tasks within timeout+10s. That we we aren't churning timer handles

EDIT: with the task overhead gone, that is where all the time gets spent

[bdraco]

That test fails locally before and after this change so I think its intent is to overload the queue but its too fast now, and my local machine is too fast as well before the change.

The queue size needs to be patched to be smaller so it can be overrun before it can be processed

[bdraco]

Maybe a RangedTimeout that does a callback on timeout
So we can timeout between 90 and 100s and only reschedule timer handles if outside range

[bdraco]

test_multiplexer_data_channel_abort_full previously relied on overloading the channel.. but it can keep up now so it doesn't overload

[bdraco]

This is functional but test_multiplexer_data_channel_abort_full needs to be fixed since it doesn't abort anymore because the performance bottleneck / cpu drain is fixed and it no longer gets so far behind that the failure happens