Auto-generate load-balancing policy and auto-retry policies

For #4530 (closed)

This MR adds client-side load-balancing and auto-retry support to Gitaly clients. The default load-balancing strategy is set to "round-robin". When gRPC client establishes a connection, if it detects, there are more than 1 subchannels after name resolution, it starts to distribute the requests to the subchannels in a round-robin fashion. Any connectivity changes are detected and handled transparently at the library layer. The corrupted subchannel is removed, and subsequent requests are evicted to other active subchannels. For more information about how client-side load-balancing works, please read this comment.

This load-balancing strategy is configured via Service Config. The service config can be configured statically when dialing or dynamically via TXT DNS Record. The dynamic approach doesn't make sense for Gitaly. Even worse, it may cause unexpected failure. As a result, this MR exposes the service config via WithDefaultLoadBalancing dial option. The client can opt in by adding this option when dialing to the host. This approach also reduces the risks comparing to adding this option by default for all clients. The downside is that we must upgrade and add this option to all clients.

By default, the library does not handle in-flight requests. When there is a corruption, client raises the Unavailable error to upper layers. In theory, this kind of error can be retried transparently. Service Config supports a flexible mechanism for auto-retry via Method Config (more about this). This MR also generates Method Config for all RPCs with OpAccessor type. Mutator RPCs are likely not safe for auto-retry. Some upsert RPCs are built with idempotency in mind, but we cannot assume that would be the case for all existing RPCs and future RPCs. As a result, upper layers are responsible for mutator RPCs retry.

I conducted some practical experiments corresponding to different ServiceConfig configurations here: #4529 (closed)