Allow Standalone nodes to operate in an orchestrated environment

[clone1018]

Essentially what this allows for is a node to act within an orchestrator network as both an ingest & edge. Serving up video directly from itself, and proxying it from other nodes as required. Working on one server as a proof of concept, but would appreciate a logic review!

Currently a test server is available at: do-nyc3-combo1.kjfk.live.glimesh.tv. You can easily stream to it and watch on Glimesh.tv and test edge functionality by using https://glimesh.github.io/janus-ftl-player/ and your favorite channel_id.

Checklist

• Watching combo1 stream from edge1 while configured as standalone
• Watching combo1 stream from combo1 while configured as standalone
• Watching ingest1 stream from combo1 while configured as standalone
• Traditional ingest functionality with orchestrator
• Traditional edge functionality with orchestrator
• Traditional standalone functionality without orchestrator

[clone1018]

Slight error on watching ingest1 stream from combo1:

janus[66953]: [2022-06-21 12:47:23.805] [info] New request watch
janus[66953]: [2022-06-21 12:47:23.805] [info] Request to watch channel 16791
janus[66953]: terminate called after throwing an instance of 'std::runtime_error'
janus[66953]:   what():  Unexpected service connection type - expected EdgeNodeServiceConnection.

[clone1018]

Seems to be fully functional now, but would appreciate feedback on a better way of handling the switch between interacting with the EdgeNodeServiceConnection (if using a relayed stream) vs XServiceConnection (if streaming directly to the Standalone node).

https://github.com/Glimesh/janus-ftl-plugin/pull/138/files#diff-d010314ca062375c6ab0cd796195ecdcd29f61cee79ed68a69d1b3dc53b74497R340-R347

[haydenmc]

Thinking through a potential ambiguity in this codepath -

Consider a scenario where a standalone FTL instance receives a watch request for a channel that has not started streaming yet. The standalone FTL server will subscribe to the channel via orchestrator.

Afterwards, the streamer actually begins streaming, but connects to the same standalone FTL server.

I suspect the orchestrator will fulfill the standalone FTL server's subscription and notify the server to relay the stream to itself.

Since only one stream can exist per channel, the standalone server will probably terminate the stream (or maybe worse, haven't really traced it through all the way).

We'll probably need special behavior to either

1.) Enlighten the orchestrator so it can handle when a standalone server tries to publish a stream on the same channel that it previously has subscribed to

2.) Enlighten the standalone FTL server so it can handle "transitioning" between a pending orchestrator relay and a "direct" stream

Thoughts?

[clone1018]

Getting back to this now, if I remember correctly there's a single remaining bug:

Viewer opens stream, combo server adds them to the pendingViewerSessions, then a new stream connects.... How do I differentiate between a new stream from an ingest, and a new stream from a user directly.

Will need to think on this tomorrow.