S2Connection should have an async-capable interface next to the sync-interface

[lfse-slafleur]

Currently we are using an async websocket framework in S2Connection and capturing it in an isolated eventloop within its own thread. Users want an async-interface as well so we would like to split the S2Connection in an async connection and a sync connection. The async connection should be used by the sync connection in its own eventloop and thread as it happens now to keep the sync interface intact. But the async connection should just expose the connection to be used in an eventloop managed by the user (or just the default eventloop).

Can be nicely combined with #135

[lfse-slafleur]

@jorritn @wcoenraads I am going to work on this shortly. Hit me up if you guys have any preferences/ideas you want incorporated

[wcoenraads]

Context: I'm coming at this with limited experience with this library (and almost no experience with async Python), but I've worked quite a bit on and with the Rust library.

My main idea around this would be that I like it when the user can manage their main loop themselves. For example, the Rust library is used like this (example from the docs):

// Send a StorageStatus message:
s2_connection.send_message(frbc::StorageStatus::new(0.5)).await?;

// Handle incoming messages:
while let Ok(message) = s2_connection.receive_message().await {
    match message.get_message() {
        // Validate the incoming message here...
        _ => { /* ... */ }
    }
     
    // Message looks good, send back an OK reception status:
    message.confirm().await?;
}

What I like about this, is that the user of the library can choose how they want to lay out their event loop. The user almost always has two sources of events (the S2 connection, and the hardware), and it's nice if they have the flexibility to interweave those however they want.

My understanding of the Python library is that does not currently allow this. The flow of the library is that you create an instance of an e.g. FRBCControlType subclass which defines how you handle messages, and give that to the S2Connection to use. Calling connection.start_as_rm() then starts the event loop. How easy is it to then e.g. spontaneously send an S2 message over that connection in response to a hardware event?

In my opinion, it would be nice if something like that is easy and clean, because I think most real RM/CEM implementations will need to do it. It might already be easy; I don't have enough practical experience with this library to know. 😄 Without more practical experience with this library I can't provide any useful concrete suggestions, but maybe this is something useful to think about!

[lfse-slafleur]

A pretty significant change may be incoming in the interface of S2Connection in s2-python by splitting it into an async and sync version and also factoring out the websocket medium into a customizable medium. Do you feel like we should keep the old S2Connection interface for legacy purposes or do you think a break would be okay?

See also:
#139
#110
#135