Keep multiple per-node remoteConns in localSite

[espadolini]

This PR makes it so that we keep track of all the open reverse tunnels coming from a node, not just the last one.

This is important during restarts, as there's no guarantee that the last connection that we accepted is from the process that will ultimately continue running instead of being a spurious connection from a process that will shut down soon after - and, in fact, the decision on which process will persist in a graceful upgrade depends entirely on the user, as it's entirely possible that the new process will get terminated and the old process is then meant to continue working as is.

Fixes a connectivity loss that occasionally happens to services behind reverse tunnel during CA rotations (as both proxy and nodes will restart multiple times), especially noticeable with the kube agent.

[espadolini]

As @fspmarshall pointed out, the one localSite's remoteConns map is a massive contention point as every reverse tunnel service (including each individual node) will attempt to register itself on every (re)start, so it might be worth it to shard it.

edit: from some local tests it seems like the contention for even 60k connections is not enough to cause issues, so it's just something to keep in mind for later

[ravicious]

Is this generally preferred to any other method of obtaining an empty slice?

[espadolini]

No, this is very much a specific trick to filter items out of a slice in-place if you know that you're the only reference to the underlying buffer. validConns is an empty slice at the beginning of conns, so appending to it will overwrite the same buffer instead of allocating a new one. This would blow up in a very weird way if we ever returned a slice to the same memory, but here we're the only ones in possession of those buffers and we're only returning copies of the values, so we're good - and avoiding allocations here it's kind of important, as this happens for all existing tunnels on every getRemoteConn.