Envoy Upstream Timeouts

When filing a bug, please include the following headings if possible. Any example text in this template can be deleted.

#### Overview of the Issue

We have observed that spuriously our envoy sidecars for some applications begin to fail to connect to upstream envoy public_listeners. This seems to happen "suddenly" in that we don't know the cause. But when it does, some of our applications begin to fail and cause a production outage.

We monitor our envoy processes with prometheus and notice a major increase in upsteram connection failures (we defined an alert with this promql to detect `sum by(consul_source_service, envoy_cluster_name) (increase(envoy_cluster_upstream_cx_connect_fail[5m])) > 0`

#### Reproduction Steps

Some assumptions details about the example below:
* client/downstream services are on EKS
* server/upstream services are on EC2
* upstream service uses tagged_addresses (there is a k8s service and endpoints object in k8s with the service's virtual ip)
* client/downstream service uses transparent proxy

1. Issue starts (still unknown cause)
2. We restart all pods for the downstream client (kubectl rollout restart)
3. New replicas are able to connect to upstreams and don't show any further error.

It's odd that restarting the "client" side pod resolves the issue. In this case, we've had multiple clients talking to the same upstream. All of the clients fail at the same time, indicating there was possibly some change in the upstream that causes communication to fail for all downstreams. Restarting all client/downstream envoy processes seems to resolve the issue

### Consul info for both Client and Server

Client info

```
agent:
check_monitors = 1
check_ttls = 0
checks = 19
services = 12
build:
prerelease =
revision = ee4911a9
version = 1.10.3
consul:
acl = disabled
known_servers = 3
server = false
runtime:
arch = amd64
cpu_count = 4
goroutines = 244
max_procs = 4
os = linux
version = go1.16.7
serf_lan:
coordinate_resets = 0
encrypted = false
event_queue = 0
event_time = 138
failed = 16
health_score = 0
intent_queue = 0
left = 127
member_time = 655889
members = 179
query_queue = 0
query_time = 2
```

Server info

```
agent:
check_monitors = 0
check_ttls = 0
checks = 0
services = 0
build:
prerelease =
revision = ee4911a9
version = 1.10.3
consul:
acl = disabled
bootstrap = false
known_datacenters = 1
leader = false
leader_addr = 172.60.1.144:8300
server = true
raft:
applied_index = 5308002
commit_index = 5308002
fsm_pending = 0
last_contact = 54.237714ms
last_log_index = 5308002
last_log_term = 846
last_snapshot_index = 5294239
last_snapshot_term = 846
latest_configuration = [{Suffrage:Voter ID:08fd2f61-3b9e-ca48-6760-8527d5e5b9b5 Address:172.60.1.144:8300} {Suffrage:Voter ID:8206ee0b-96b9-b389-dcb5-34afdd544aa2 Address:172.60.1.152:8300} {Suffrage:Voter ID:9e27d86a-f0a3-bca2-d4df-03864b61d241 Address:172.60.0.18:8300}]
latest_configuration_index = 0
num_peers = 2
protocol_version = 3
protocol_version_max = 3
protocol_version_min = 0
snapshot_version_max = 1
snapshot_version_min = 0
state = Follower
term = 846
runtime:
arch = amd64
cpu_count = 4
goroutines = 642
max_procs = 4
os = linux
version = go1.16.7
serf_lan:
coordinate_resets = 0
encrypted = false
event_queue = 0
event_time = 138
failed = 1
health_score = 2
intent_queue = 0
left = 112
member_time = 655888
members = 149
query_queue = 0
query_time = 2
serf_wan:
coordinate_resets = 0
encrypted = false
event_queue = 0
event_time = 1
failed = 0
health_score = 0
intent_queue = 0
left = 0
member_time = 250
members = 3
query_queue = 0
query_time = 1
```

### Operating system and Environment details

We're using EKS 1.18 for servers and k8s-workloads
Our EC2 instances are either Centos7, or AL2

I've built custom binaries based on 1.10.3 with a patch for #8283 and #11422 - nothing else was changed

### Log Fragments

I have spent a lot of time looking for logs related to this issue. I don't see _any_ logs in our envoy processes during these issues. The only logs we see are when we start to terminate the envoy processes to restart them.

If someone thinks that increasing log verbosity for envoy would be helpful we can increase them and wait for this issue to reoccur. Please provide details on how to increase the log verbosity if this is helpful.