Shift from Threading to asyncio (Event-Driven Execution)

[RaulSMS]

The current implementation utilizes OS-level threads (threading.Thread) combined with synchronous queues (queue.Queue) to continuously poll the python-can interface for incoming J1939 frames.

• This approach results in significant CPU overhead during high-bus-load scenarios (e.g., streaming 250kbps or 500kbps CAN streams with extensive background traffic).
• Handling protocol timeouts (such as waiting for Transport Protocol RTS/CTS handshakes or multi-packet frame sequences) relies on manual clock/delta calculations or blocking queue.get(timeout=...) patterns scattered across separate thread routines.

Proposed Architecture Fix

Migrate the primary communication and polling loop to an asynchronous event loop using Python 3.10's native asyncio.

1. Use an asynchronous variant or an async-compatible wrapper for the underlying python-can Bus listener.
2. Replace background threads with non-blocking tasks (asyncio.create_task()).
3. Leverage native asynchronous timeout contexts (asyncio.wait_for()) to manage state lifecycle expirations smoothly.

Warning

This is a major change and may introduce braking changes