Abstracting out media transport protocols

[jackjansen]

I think it would be a good idea to "abstract out" the transport protocols (currently TCP, SocketIO, Dash and WebRTC underway).

Here's the basic idea. Comments please.

First the transport protocol handlers in VR2Gather become structured like the user representations are now. The implementations get a static initialiser that registers the implementation class with a VRTTransportProtocolRegistry by name. All transport protocol classes derive from some VRTAbstractTransportProtocol, and that's the class that is used everywhere else in the code. The list of names in the transport protocol popup menu in Create Session would also be populated from the VRTTransportProtocolRegistry.

Once this is implemented @jvdrhoof doesn't have to clone the VR2Gather repo for development: he can simply create a VRTApp and call the right registration method there.

Next step is that the Orchestrator gets an API to allow getting the list of supported transport protocols. Probably the code on the side of the orchestrator could be structured along similar lines (with a registry by name for supported transport protocols). For a specific combination of orchestrator/VR2Gather the list of supported protocols would then be the intersection of the two lists. tcp would always be supported (because the orchestrator doesn't have to do anything for it).

This also seems to be a good reason to structure the socketio handling similar to the dash and webrtc protocols: have it be handled by a separate SFU-like process, on a different port. This, in turn, means that we can eventually replace the orchestrator by something else.

Edit: that paragraph is no longer our current thinking: we will provide a TCP SFU and possibly later also a message queue sfu.

[jackjansen]

I would like to also assign @jvdrhoof but that seems to be impossible?

[jackjansen]

Have to fix #157 first to remain sane.

[ireneviola]

Is this needed for June 3rd (Tom doesn't think so), or is it a nice-to-have?