Orchestrator should not do own connection capping when using remote transcoders

Nobody has claimed this yet.

Orchestrator's own connection capping was created for orchestrator doing transcoding by itself. For remote transcoders, there is another mechanism protecting transcoders from overload (each transcoder specifies own cap and orchestrator doesn't send more jobs then that cap to transcoder). But when remote transcoders connected, own orchestrator's capping still works, and takes precedence of transcoder's capping. That means that user should not forget to set `-masSessions` parameter on orchestrator to some high number which is higher then sum of cap of connected remote transcoders.
This is not great UX, we should automatically turn of orchestrator's connection capping when it works with remote transcoders.

Start by tracing the orchestrator's connection-capping logic and the remote transcoder session-cap handling; the issue does not name files or tests. Done means remote transcoders use their own aggregate caps without requiring a manually increased orchestrator cap, while local transcoding behavior remains intact.

Written by the indexing model from the issue text.