policy: restore ConnectionIdle to 120s (matches upstream v2node; fixes idle SSH/long-lived connections dropping at ~60s)

[echoowall]

Problem

core/xray.go sets the level-0 policy ConnectionIdle to 30s:

ConnectionIdle: proto.Uint32(30),

xray closes a proxied connection once there is no application-layer data for ConnectionIdle seconds, and it enforces this with a polling activity timer (common/signal/timer.go): the check runs every ConnectionIdle seconds and only fires after a full interval with no activity following the one that consumed the previous activity token — so the effective timeout is ~2× the value, i.e. ~60s for 30.

The result: idle-but-healthy long-lived connections — interactive SSH, database/Redis, MQTT, WebSocket — are dropped after ~60s of silence even though the socket is perfectly fine. TCP keepalive does not help (it refreshes the socket, not this application-level timer).

On an affected node, a packet capture of an idle proxied SSH session showed the node itself sending FIN at exactly the 60s mark, with TCP keepalives still flowing on both legs — confirming an application-level idle timeout rather than a NAT/socket issue.

Context

• This project is modified from wyx2685/v2node, which uses ConnectionIdle: 120. ppnode lowered it to 30 (4× more aggressive) at some point.
• xray-core's own default is 300s (SessionDefault) / 600s (default manager) — so 30s is ~10–20× more aggressive than xray itself.

Fix

Restore ConnectionIdle to 120, matching upstream v2node. Verified end-to-end: with 30 an idle SSH tunnel dropped at ~60s every time; with the larger value the same tunnel stays up (no drop observed to 200s+).

A cleaner long-term fix would be to expose this as a config field (as v2node/V2bX do) instead of a hardcoded constant, so operators can tune it without patching source.

[echoowall]

Extra findings (why 30s behaves like ~60s, and how it compares to xray / V2bX defaults)

The effective timeout is ~2× the configured value.
xray enforces ConnectionIdle with a polling activity timer (common/signal/timer.go): SetTimeout(d) starts a task.Periodic{Interval: d, Execute: check}, and each check() consumes at most one activity token. A connection that goes idle right after setup survives the first check (which consumes the setup's token) and is only closed on the second check — i.e. after ~2·d. So ConnectionIdle: 30 actually tears connections down at ~60s, which matches the packet capture (node sends FIN at 60.0s).

30s is far below xray's own default. xray-core defaults ConnectionIdle to 300s (features/policy/policy.go SessionDefault) / 600s for the default manager (features/policy/default.go). This project overrides that with 30s — ~10–20× more aggressive — which silently breaks idle-but-alive long-lived connections (interactive SSH, DB/Redis, MQTT, WebSocket).

vs V2bX: V2bX ships the same 30 default, but exposes it as a configurable field (connIdle in the xray config, core/xray/xray.go uses &c.ConnIdle), so operators can raise it. Here it's a hardcoded constant, so there is no way to change it without patching the source.

This PR just raises the constant. A cleaner long-term fix would be to expose it as a config option like V2bX does, defaulting to something no more aggressive than xray's own default.