Modularise the transport layer

[urbanmatthias]

As a first steps towards an ReSTful OSP-API, we should make it easy to plug in different transport modules.

1. Move the transport module files to a different namespace (maybe from osp.transport.default import TransportSession and osp.transport.ospapi import OspApiSession ?). I would try to make sure that the old imports still work, but produce a deprecation warning.
2. Maybe move the entire transport layer to a different repository. I would say this is not necessary at the moment, though. What do you think @yoavnash @aaronAB1993 does this make sense?
3. Maybe we can create abstract classes like we do for wrappers, to make it easy to create new transport modules.
4. Then we can also create some empty transport layer files like https://gitlab.cc-asp.fraunhofer.de/simphony/wrappers/wrapper-development/-/blob/master/osp/wrappers/some_simulation_session.py

Any other ideas?

[aaronAB1993]

I think modularising is a very nice idea in general. For some DSMS questions I bumped into the transport layer several times and I think from a modular perspective, the DSMS is simply an extended transport layer. I would start with option 1.. Option 2. is a bit overkill at the moment but I think at some point it might become handy (e.g. the DSMS is in another repo as well). About option 3/4.: Yes, abstract classes would be nice. I see that for wrappers, it is really helpful, so why not for transport sessions? I think the challenge here is that we always have client and server side, i.e. two classes that need to match with each others implementation. I am not sure how to put this into abstract classes (apart from abstract classes on each side).

[yoavnash]

Sounds good to me