pool: reap miners that have said nothing for ten minutes

A Miner left gMiners in exactly one place: RecvLine reporting a clean
disconnect. Half-open TCP sessions send no FIN and raise no error, so
they lived forever -- on the live pool authorize outpaced disconnect
2:1, over half the table never submitted a share, and the leak grew
toward MAX_POOL_MINERS, past which the accept path refuses real miners.

Two changes. First, an idle reap in the event loop's miner sweep: any
miner whose last activity is older than POOL_IDLE_TIMEOUT_SECS (600s)
is closed and erased through exactly the bookkeeping the
clean-disconnect path uses -- log, sock_close, erase via std::find,
delete -- collected into a side vector first so the sweep's iteration
stays valid. Shares an idle miner already earned stay in
roundShareCount, just as they do when a miner cleanly disconnects
mid-round. To give the reap something honest to measure, lastSeen is
now stamped on every complete line received (authorize and valid shares
already stamped it; a miner that only subscribes, or sends
unrecognised methods, previously looked dead from birth), with
connectTime standing in for a connection that never completed a line.
Ten minutes is far beyond the 15s vardiff share target and the 45s
stall watchdog, so no miner that is actually hashing comes close.

Second, SO_KEEPALIVE on sockets accepted by the loopback stratum
listener, so a half-open session eventually errors out of recv and
lands in the reap path on its own. This is a backstop only: the default
cadence before the first probe is hours on most stacks, so the idle
timeout fires long before keepalive does. Miners arriving via a relay
ride a loopback socket pair whose real transport is the rendezvous
socket owned by the tunnel pump threads, which keepalive cannot reach
across -- for those the idle reap is also what finally tears the tunnel
down, since closing the app end unblocks the pumps.

Closes #6

0 files changed, 0 insertions, 0 deletions