RPC production plumbing: discovery bootstrap, a connection pool, and the TLS story

[sshaplygin]

Part of #63.

Two rows of docs/rpc-compatibility.md describe the same problem from different ends: gate D — discovery bootstraps without being told a proxy — is not started, and layer 3 records one connection per client, with no pool, no per-proxy health and no banning.

That shape works against a cluster whose proxy you can name in a config file. It does not survive a real installation, where there are many RPC proxies, some fraction of them unhealthy at any moment, and neither reference client asks the user to pick one.

DiscoverProxies over RPC is implemented — but it needs a proxy already, which is the whole of gate D. The HTTP discover_proxies route both reference clients bootstrap from is deliberately absent from ytsaurus-rpc, because it would drag an HTTP stack into a crate that has none; ytsaurus-client already speaks HTTP v4 and can answer it.

• HTTP discover_proxies bootstrap, sourced from ytsaurus-client rather than by adding an HTTP stack here
• a connection pool: per-proxy health, banning a proxy that fails, re-discovery on a timer, and a documented policy for what happens to an in-flight request when its proxy is banned
• settle the TLS story. A peer that requires encryption is currently refused rather than downgraded — the right default and an incomplete answer. Either the bus speaks TLS, or that is a recorded non-goal with the reason attached.
• gate D goes green in docs/rpc-compatibility.md, or its wording changes to match what was decided