Add v3 xDS support (envoyproxy#140)

* Add v3 xDS support

This commit adds support for the v3 xDS transport as well as support for
storing and serving v3 resources out of the resource cache.

Note that resource versions and xDS transport version are decoupled to
provide a migration path to v3. End users can decide to generate v3
resources and serve them over v2 transport during migration, or continue
to generate v2 resources and serve them over v3 transport.

For implementation simplicity, it is not possible to generate a
combination of v2 and v3 resources in the control plane, which would
require either up or down conversion.

Signed-off-by: Michael Puncel <[email protected]>

* PR comments: move type URLs to their own static class. Fix broken javadoc link. Use method overloading instead of different names for v2 vs v3 node hash

Signed-off-by: Michael Puncel <[email protected]>

* PR comments: use package names to differentiate v2 and v3 cache types

Signed-off-by: Michael Puncel <[email protected]>

* put tests in v2 and v3 packages

Signed-off-by: Michael Puncel <[email protected]>

* rename v2 onStreamRequest callback, remove default implementation

Signed-off-by: Michael Puncel <[email protected]>

* rename onStreamRequest on DiscoveryServerCallbacks

Signed-off-by: Michael Puncel <[email protected]>

* DRY most of the DiscoveryServerCallbacks implementations in integration tests

Signed-off-by: Michael Puncel <[email protected]>

* make v3 transport integration tests also use v3 resource version

Note that there are not tests that cover a different transport version
from resource version in the interest of not doubling the number of
integration tests.

Signed-off-by: Michael Puncel <[email protected]>

* update README and add v2 -> v3 guide

Signed-off-by: Michael Puncel <[email protected]>

Author: mpuncel

README.md

@@ -7,6 +7,12 @@ in [data-plane-api](https://github.com/envoyproxy/data-plane-api). It started li
 [go-control-plane](https://github.com/envoyproxy/go-control-plane), but building an idiomatic Java implementation is
 prioritized over exact interface parity with the Go implementation.
 
+Both v2 and v3 resources as well as transport versions are supported. Migrating
+to v3 is recommended as Envoy will drop v2 support at EOY 2020 (see
+[API_VERSIONING.md](https://github.com/envoyproxy/envoy/blob/4c6206865061591155d18b55972b4d626e1703dd/api/API_VERSIONING.md))
+
+See the (v2-to-v3 migration guide)[V2_TO_V3_GUIDE.md] for an exmplanation of migration paths.
+
 ### Requirements
 
 1. Java 8+

V2_TO_V3_GUIDE.md

@@ -0,0 +1,41 @@
+# Migrating from xDS v2 to v3
+
+To faciliate migrating from the v2 xDS APIs to v3, this repo supports both the
+v2 and v3 gRPC transports, with each transport supporting type URL rewriting of
+DiscoveryResponse to whatever version the client requests with
+api_resource_version.
+
+The migration requires care - for example, using v3-only fields too soon or trying to use
+deprecated v2 fields too late can cause Envoy to reject or improperly apply config.
+
+### Recommended Sequence
+
+This section assumes you have sufficient control over Envoy sidecar versions that you do
+not need to run v2 and v3 simultaneously for a long migration period.
+
+1. Make sure your oldest Envoy client supports final v2 message versions.
+2.
+    1. Ensure your control plane is not using any deprecated v2 fields.
+    Deprecated v2 fields will cause errors when they are translated to v3
+    (because deprecated v2 fields are dropped in v3).
+    2. Configure a V3DiscoveryServer alongside the V2DiscoveryServer in your
+    control plane.  You can (and should) use the same (v2) Cache implementation
+    in both servers.
+3. Deploy all Envoy clients to switch to both the v3 transport_api_version and
+   resource_api_version in each respective xDS configs. As this happens, the V3DiscoveryServer
+   will be translating your v2 resources to v3 automatically, and the V2DiscoveryServer will
+   stop being used.
+4.
+    1. Rewrite your control plane code to use v3 resources, which means using
+    V3SimpleCache (if you use SimpleCache). You may now start using v3-only
+    message fields if you choose.
+    2. Drop the V2DiscoveryServer.
+
+### Alternative
+
+Another possible path to the one above is to switch to generating v3 in the
+control plane first (e.g. by using V3SimpleCache) and then deploying Envoy
+clients to use v3 transport and resource versions.
+
+This approach requires care to not use new V3-only fields until the client side
+upgrade is complete (or at least understand the consequences of doing so).