Pool should close connections that go for too long without any channels

[plebhash]

the hosted SRI Pool has some automations that periodically report the stats to me

here's an example:

━━━ Mainnet (port 3333) ━━━
Uptime: 12d 7h 15m
Clients: 49
Channels: 25 (25 ext, 0 std)
Hashrate: 1.37 PH/s
  • Client 1001: 0 ch (0 ext, 0 std) | Total: 0 H/s
  • Client 806: 0 ch (0 ext, 0 std) | Total: 0 H/s
  • Client 477: 0 ch (0 ext, 0 std) | Total: 0 H/s
  • Client 565: 1 ch (1 ext, 0 std) | Total: 576.11 GH/s
      ├─ Ch 2 (ext): 576.11 GH/s
  • Client 814: 0 ch (0 ext, 0 std) | Total: 0 H/s
  • Client 502: 0 ch (0 ext, 0 std) | Total: 0 H/s
  • Client 564: 0 ch (0 ext, 0 std) | Total: 0 H/s
  • Client 618: 0 ch (0 ext, 0 std) | Total: 0 H/s
  • Client 711: 3 ch (3 ext, 0 std) | Total: 2.50 TH/s
      ├─ Ch 6 (ext): 1.02 TH/s
      ├─ Ch 8 (ext): 845.14 GH/s
      ├─ Ch 7 (ext): 630.42 GH/s
  • Client 738: 0 ch (0 ext, 0 std) | Total: 0 H/s
  • Client 747: 0 ch (0 ext, 0 std) | Total: 0 H/s
  • Client 74: 1 ch (1 ext, 0 std) | Total: 1.51 TH/s
      ├─ Ch 2 (ext): 1.51 TH/s
  • Client 547: 0 ch (0 ext, 0 std) | Total: 0 H/s
  • Client 527: 0 ch (0 ext, 0 std) | Total: 0 H/s
  • Client 579: 1 ch (1 ext, 0 std) | Total: 1.06 TH/s
      ├─ Ch 2 (ext): 1.06 TH/s
  • Client 503: 0 ch (0 ext, 0 std) | Total: 0 H/s
  • Client 723: 13 ch (13 ext, 0 std) | Total: 1.35 PH/s
      ├─ Ch 161 (ext): 805.97 GH/s
      ├─ Ch 12 (ext): 150.00 TH/s
      ├─ Ch 16 (ext): 50.00 TH/s
      ├─ Ch 155 (ext): 1.00 TH/s
      ├─ Ch 106 (ext): 150.00 TH/s
      ├─ Ch 14 (ext): 150.00 TH/s
      ├─ Ch 112 (ext): 150.00 TH/s
      ├─ Ch 13 (ext): 150.00 TH/s
      ├─ Ch 51 (ext): 150.00 TH/s
      ├─ Ch 26 (ext): 50.00 TH/s
      ├─ Ch 43 (ext): 50.00 TH/s
      ├─ Ch 8 (ext): 150.00 TH/s
      ├─ Ch 28 (ext): 150.00 TH/s
  • Client 1: 1 ch (1 ext, 0 std) | Total: 0 H/s
      ├─ Ch 2 (ext): 0 H/s
  • Client 932: 0 ch (0 ext, 0 std) | Total: 0 H/s
  • Client 581: 1 ch (1 ext, 0 std) | Total: 1.07 TH/s
      ├─ Ch 2 (ext): 1.07 TH/s
  • Client 84: 0 ch (0 ext, 0 std) | Total: 0 H/s
  • Client 433: 0 ch (0 ext, 0 std) | Total: 0 H/s
  • Client 454: 0 ch (0 ext, 0 std) | Total: 0 H/s
  • Client 592: 0 ch (0 ext, 0 std) | Total: 0 H/s
  • Client 813: 0 ch (0 ext, 0 std) | Total: 0 H/s


━━━ Testnet4 (port 43333) ━━━
Uptime: 11d 22h 52m
Clients: 0
Channels: 0 (0 ext, 0 std)
Hashrate: 0 H/s

there's multiple entries with 0 channels and 0 H/s

this was causing great confusion, even leading to a misleading issue written by myself last month: #319

I originally thought this was some kind of memory leak around this HashMap:

sv2-apps/pool-apps/pool/src/lib/channel_manager/mod.rs

Lines 60 to 63 in 3773dd5

	pub struct ChannelManagerData {
	// Mapping of `downstream_id` → `Downstream` object,
	// used by the channel manager to locate and interact with downstream clients.
	pub(crate) downstream: HashMap<DownstreamId, Downstream>,

I was suspecting that we were keeping track of Downstream objects (and reporting them via HTTP API probes) even after they disconnected

this theory doesn't make too much sense however, because the client ids listed above have very high numbers (some as high as 1000)... if we had consistent memory leaks, I'd expect to see ~900 entries for empty clients

then I realized that there is a much simpler explanation: any tProxy that is connected to the hosted SRI Pool, but without any Sv1 downstream client, will show up as an empty client in the list above

---

Braiins has a policy of disconnecting clients if they don't open any channel in a few seconds

I think it makes sense to have something similar on SRI Pool

afterall, what's the point in maintaing an idle connection? it's consuming Pool resources for nothing

as long as we do a generous interval (to avoid accidental disconnections due to operational issues), this feels like the right thing to do

[plebhash]

a naive solution would be to close the connection if it doesn't open any channel after X seconds

but I think the solution should also cover scenarios where there were open channels, which were later closed and the connection became idle