Evaluate node-to-client communication via TCP

The node-to-client mini-protocols are only available via unix-socket connections. AFAIK, the goal of this constraint is to reduce the attack surface, improving security.

Although valid, this approach limits the deployment options at the infrastructure level. A setup that includes Cardano Node, DBSync, Ogmios, Submit-API, etc forces the operator to merge the workload under a single host, which is far from ideal.

Allowing each component to run in a different hosts brings several benefits: horizontal scaling, high-availability, resource isolation, etc. Many operators from the community have relied on workarounds (eg: UNIX <=> TCP socat tunnels) to escape the constrained imposed by the Node.

On a private network topology, having a way to enable node-to-client communication via TCP would simplify configuration and introduce new deployment options. This option should be disabled by default and would require an explicit opt-in from the operator to enable it.

Start with the node-to-client mini-protocols and their current Unix-socket-only deployment described in the issue; no file or test entry point is named. Evaluate the security and opt-in requirements for TCP against the Cardano Node, DBSync, Ogmios, and Submit-API deployment scenario, with a clear recommendation as the outcome.

Written by the indexing model from the issue text.