When providing updates to Envoy it is safest to follow the update order
of: Clusters, Endpoints, Listeners, Routes. This order is encoded in our
delta xDS response generation code.

Another noteworthy attribute of these resources is that there are
parent->child relationships between: Cluster->Endpoints and
Listener->Routes. Envoy couples the storage of a parent and a child type
such that whenever a control plane sends an update for a parent type, it
MUST also send fresh data for the child type, even if Envoy previously
had the latest data for the child type.

A wrinkle that isn't accounted for currently is that Envoy does not
actually ACK parent types until after attempting to receive data for the
child types. This behavior also actually differs between Clusters and
Listeners:
- When a cluster is sent, Envoy will wait up to a 15s timeout for
  endpoints to arrive before sending the cluster ACK.
- When a listener is sent, and it specifies RDS routes, Envoy will wait
  until those routes arrive before ACKing the listener. Though it's not
  clear to me what the timeout is for this, it exceeds a minute from my
  tests.

However, a behavior encoded in our xDS update order is that we avoid
sending ANY data if we are waiting on ACKs for ANY resource. Meaning
that when we first send a cluster to Envoy and it requests endpoints for
that cluster, the endpoints do not actually get sent for at least 15.
This is because the endpoint update is paused by Consul until the
cluster ACK, which Envoy pauses until it gets endpoints or times out.

This commit changes the xDS order gating such that we only block
listener/route updates if there are cluster/endpoin updates pending.
This is to avoid routing to an invalid destination.