Cluster peering commands have a 1 in N consul servers chance of succeeding

It seems that only when a Consul server node is the active raft leader that `consul peering` related commands can be run against it (follower nodes simply fail with `Error listing peerings`, for example)

On follower nodes, the errors being logged read:
```
[core]grpc: addrConn.createTransport failed to connect to {__cluster_name__-__internal_lan_ip__:8300 leader
transport: Error while dialing failed to find Consul server for global address "__cluster_name__-__internal_lan_ip__:8300"
```
where `__cluster_name__` and `__internal_lan_ip__` are both valid, and there is no issues with line of sight/CA certificates/etc - from any node logging the error, line of sight can be confirmed with `telnet __internal_lan_ip__ 8300` and the connection attempt is logged on the remote end

Start by reproducing the `consul peering` commands against follower and leader Consul server nodes, then trace the logged gRPC address-resolution failure and the Raft leader interaction. Done means peering commands succeed when sent to follower nodes as well as the active leader, without the reported `Error listing peerings` failure.

Written by the indexing model from the issue text.