Emissary-Ingress - v2.3.0

:tada: Emissary Ingress 2.3.0 :tada:

Emissary Ingress is an open source, Kubernetes-native microservices API gateway built on the Envoy Proxy.

Upgrade Emissary - https://www.getambassador.io/reference/upgrading.html
View changelog - https://github.com/emissary-ingress/emissary/blob/v2.3.0/CHANGELOG.md
Get started with Emissary on Kubernetes - https://www.getambassador.io/user-guide/getting-started

• Security: Completely remove gdbm, pip, smtplib, and sqlite packages, as they are unused.

• Feature: It is now possible to set propagation_modes in the TracingService config when using
  lightstep as the driver. (Thanks to Paul!) (#4179)

• Feature: It is now possible to set crl_secret in Host and TLSContext resources to check peer
  certificates against a certificate revocation list. (#1743)

• Feature: Previously, a LogService would always have Emissary-ingress communicate with the
  external log service using the envoy.service.accesslog.v2.AccessLogService API. It is now
  possible for the LogService to specify protocol_version: v3 to use the newer
  envoy.service.accesslog.v3.AccessLogService API instead. This functionality is not available if
  you set the AMBASSADOR_ENVOY_API_VERSION=V2 environment variable.

• Bugfix: When CORS is specified (either in a Mapping or in the Ambassador Module), CORS
  processing will happen before authentication. This corrects a problem where XHR to authenticated
  endpoints would fail.

• Bugfix: In 2.x releases of Emissary-ingress when there are multiple Mappings that have the same
  metadata.name across multiple namespaces, their old config would not properly be removed from
  the cache when their config was updated. This resulted in an inability to update configuration for
  groups of Mappings that share the same name until the Emissary-ingress pods restarted.

• Bugfix: It is now possible for a TracingService to specify collector_endpoint_version: HTTP_JSON_V1 when using xDS v3 to configure Envoy (which has been the default since
  Emissary-ingress 1.14.0). The HTTP_JSON_V1 value configures Envoy to speak to Zipkin using
  Zipkin's old API-v1, while the HTTP_JSON value configures Envoy to speak to Zipkin using
  Zipkin's new API-v2. In previous versions of Emissary-ingress it was only possible to use
  HTTP_JSON_V1 when explicitly setting the AMBASSADOR_ENVOY_API_VERSION=V2 environment variable
  to force use of xDS v2 to configure Envoy.