Configurable bootstrap timeout for existing clusters

[pchaseh]

What would you like to be added?

GetClusterFromRemotePeers uses a hard-coded 10s timeout which is called when bootstrapping an etcd member against an existing cluster. This could be configurable via the existing bootstrap timeout option.

Why is this needed?

This has bit me amidst attempting to add new etcd members to my cluster which was being used with Patroni for a high-availability PostgreSQL setup, where-in the members endpoint was taking a few hundred milliseconds more than the fixed 10 second timeout. Of course, the source of the problem is that my etcd members could not reply in a timely manner (for which the cause remains TBD), but the ability to override this at runtime could have saved me a lot of time (I did try redeploying etcd with increased timeouts, however it took me some time to realize that none of them were applicable when bootstrapping from an existing cluster, so I had to build my own etcd container with code changes). I'd be happy to submit a patch for this assuming it's a desirable feature