[BUG] Bettercap event processing loop fails

[matrix224]

Describe the bug
While looking into and playing with my reports from issue 125, I noticed another thing that has potential to go wrong. It's in a similar ballpark as that issue, but I felt it was different enough to warrant a separate report.

The processing loop for handling bettercap events in method start_websocket in bettercap.py can fail indefinitely if an unhandled exception is thrown in there. Currently it explicitly handles ConnectionRefusedError and OSError, but any other exception can / will end up causing that processing to fail.
This has not been a common occurrence for me, so I assume it's not a typical thing to see. But it can still happen and when it does, essentially just leaves the pwnagotchi running in limbo where it repeatedly sends association and deauth frames to devices, but will never actually be aware of when any handshakes are captured.

I provide samples and further explanations in the Additional Context below.

To Reproduce
I unfortunately don't have any explicit steps to cause this again as it seems to most likely occur when bettercap dies

1. Run the pwnagotchi in auto / AI mode as normal
2. Wait for bettercap to die
3. The start_websocket method may possibly encounter an unhandled exception during this time

Expected behavior
The start_websocket should handle any exception to keep the loop processing

Screenshots
N/A

Environment (please complete the following information):

• 1.8.5
• Pi Zero 2

Additional context

This is the actual stack trace from the error:

[2024-05-05 01:14:47,584] [ERROR] Task exception was never retrieved
future: <Task finished coro=<Client.start_websocket() done, defined at /usr/local/lib/python3.7/dist-packages/pwnagotchi/bettercap.py:51> exception=InvalidMessage('did not receive a valid HTTP response')>
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/dist-packages/websockets/client.py", line 101, in read_http_response
    status_code, reason, headers = await read_response(self.reader)
  File "/usr/local/lib/python3.7/dist-packages/websockets/http.py", line 139, in read_response
    status_line = await read_line(stream)
  File "/usr/local/lib/python3.7/dist-packages/websockets/http.py", line 213, in read_line
    line = await stream.readline()
  File "/usr/lib/python3.7/asyncio/streams.py", line 496, in readline
    line = await self.readuntil(sep)
  File "/usr/lib/python3.7/asyncio/streams.py", line 588, in readuntil
    await self._wait_for_data('readuntil')
  File "/usr/lib/python3.7/asyncio/streams.py", line 473, in _wait_for_data
    await self._waiter
  File "/usr/lib/python3.7/asyncio/selector_events.py", line 801, in _read_ready__data_received
    data = self._sock.recv(self.max_size)
ConnectionResetError: [Errno 104] Connection reset by peer

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.7/dist-packages/pwnagotchi/bettercap.py", line 73, in start_websocket
    async with websockets.connect(s, ping_interval=ping_interval, ping_timeout=ping_timeout, max_queue=max_queue) as ws:
  File "/usr/local/lib/python3.7/dist-packages/websockets/client.py", line 517, in __aenter__
    return await self
  File "/usr/local/lib/python3.7/dist-packages/websockets/client.py", line 547, in __await_impl__
    extra_headers=protocol.extra_headers,
  File "/usr/local/lib/python3.7/dist-packages/websockets/client.py", line 290, in handshake
    status_code, response_headers = await self.read_http_response()
  File "/usr/local/lib/python3.7/dist-packages/websockets/client.py", line 103, in read_http_response
    raise InvalidMessage("did not receive a valid HTTP response") from exc
websockets.exceptions.InvalidMessage: did not receive a valid HTTP response

Based on the code from agent.py in the _event_poller method, I'm assuming the intention was that any unhandled exceptions would be thrown up and handled in there. But that does not appear to be how this works due to the use of asyncio loops.
From my light research into it, it looks like there are certain ways you're supposed to handle exceptions using these loops. Unfortunately I only really use Python as a hobby language, so I don't know what the best way to fix it using that methodology would be. I'm assuming there's probably a better way to implement and use the loops in this case, but I can't give any real opinion on it.

Personally, on my local build, I just updated start_websocket in bettercap.py to also catch generic Exception and handle it the same way it does with the other two already handled cases. I've been running for about 13 hours non-stop so far now, though it doesn't appear that it has caught any exceptions in that block yet, so I can't say for certain if this is good or not.