Redesign the vehicle loop based on concurrency and not multithreading

[DocGarbanzo]

Redesign the vehicle loop

Current state

Currently we are using blocking or threaded parts using the python threading library. Also, we need to specify specific arguments to each part's run function, which is poor OO design.

Future plan

• Use concurrency, i.e. asyncio probably in the form of trio (https://trio.readthedocs.io/en/stable/) to run all parts independently of each other at independent frequencies.
• Create a base class for the parts and provide a factory-based initialisation, that can read from a yaml file
• Create an OO interface for the parts as a replacement of run. Parts should read/write to a common memory object
• Create a dynamic module reader, so users can place code for their parts into the ~/mycar directory, these can then be used in the car w/o tinkering w/ the donkeycar code

[sctse999]

I think this is great and long awaited one. It’s particularly painful to specify argument in each part.

[fengye]

To add to the current state: lots of the parts code have no protection or whatsoever of accessing variables from worker thread(run_threaded) and main thread(update, etc), makes the code not reliable(quite often stale when exiting a drive session) and looks loose.