Metadata provides additional inputs to filters based on matched listeners,
filter chains, routes and endpoints. It is structured as a map from filter
name (in reverse DNS format) to metadata specific to the filter. Metadata
key-values for a filter are merged as connection and request handling occurs,
with later values for the same key overriding earlier values.

An example use of metadata is providing additional values to
http_connection_manager in the envoy.http_connection_manager.access_log
namespace.

For load balancing, Metadata provides a means to subset cluster endpoints.
Endpoints have a Metadata object associated and routes contain a Metadata
object to match against. There are some well defined metadata used today for
this purpose:

{"envoy.lb":{"canary":<bool>}} This indicates the canary status of an
endpoint and is also used during header processing
(x-envoy-upstream-canary) and for stats purposes.

Configuration for transport socket in listeners and
clusters. If the configuration is
empty, a default transport socket implementation and configuration will be
chosen based on the platform and existence of tls_context.

{"name":"...","config":"{...}"}

name

(string, REQUIRED) The name of the transport socket to instantiate. The name must match a supported transport
socket implementation.

config

(Struct) Implementation specific configuration which depends on the implementation being instantiated.
See the supported transport socket implementations for further documentation.

Envoy supports upstream priority routing both at the route and the virtual
cluster level. The current priority implementation uses different connection
pool and circuit breaking settings for each priority level. This means that
even for HTTP/2 requests, two physical connections will be used to an
upstream host. In the future Envoy will likely support true HTTP/2 priority
over a single upstream connection.