check if it is better to use async functions for ethernet socket receive/send rather than blocking functions in threads

[jimy-byerley]

At the moment, the library is async for everything at the ethercat level, but is sync for the socket stuff. Ending up in the following case:

// at the moment
let master = Arc::new(Master::new(/* ... */));
// sync threads for socket receive/send
{
    let master = master.clone();
    std::thread::spawn(move || loop {
    unsafe {master.get_raw()}.receive();
})};
{
    let master = master.clone();
    std::thread::spawn(move || loop {
    unsafe {master.get_raw()}.send();
})};
// then async stuff using ethercat

This could be replaced or completed with the possibility of handling the socket with async socket functions like in async-std and ethercrab internals

async-std however does not provide raw sockets, so these async raw sockets should be implemented directly using libc like it is currently in blocking mode.

The performance benefit is unknown:

• Maybe this will lead to performance improvement because avoiding the thread-context switching between the async runtime and the socket handling threads
• or maybe polling the sockets by the async runtime will be less reactive than a blocking function

[jimy-byerley]

In the end, it proved to be much more reliable to use async socket instead of blocking sockets