Bound the TCP client's connect timeout instead of int.MaxValue

[MonoFinity]

The problem

TCPCommunicationLayer.CreateClient() passes int.MaxValue as VoltRpc's connectionTimeout:

return new TCPClient(ipEndPoint, int.MaxValue);

That is roughly 24 days of retrying. Against an engine process that is already gone the connect loop never terminates — and because a Unity domain reload has to tear the client down, the reload blocks on it. The symptom is the Editor sitting on Reloading Domain (busy for HH:MM) indefinitely rather than reporting a failed connection.

This is easy to hit in the Editor: any time the engine dies or is reaped (a crash, a stale process from a previous Play session, a port collision), the next domain reload wedges instead of surfacing the real failure. Recovering means killing the Editor.

The change

Make it a serialized field with a 30 s default:

[Range(1000, 600000)] [Tooltip("Give up connecting to the engine after this long (ms)")]
public int connectionTimeout = 30000;

So a dead engine surfaces as a connection failure, and a domain reload can always complete. The range leaves room for anyone who needs a longer wait on a slow cold start.

Why CreateHost() is left alone

CreateHost() also passes int.MaxValue, twice — but it's the listening side rather than a retry loop, and we've never observed it blocking a reload, so I didn't want to change it speculatively. Happy to bound it here too for symmetry if you'd prefer; just say which value.

Notes

• Verified against master (f49743d).
• We've been running this in a vendored copy of 2.2.8; it turned a recurring multi-hour Editor wedge into a clean 30 s failure message.
• Independent of Gate the native engine on the host OS, not the active build target #439 (host-OS engine gate) — either can be taken without the other.