grpc: add explicit nonce to DiscoveryResponse. (#172)

This is a fix for a potential race that exists in the gRPC
implementation today. Namely:

1. Envoy sends a DiscoveryRequest at X with resources {A, B}
2. Management server responds with DiscoveryResponse at X+1.
3. Envoy decides (for whatever reason) to change resources before
   beceiving the X+1 response. It sends a DiscoveryRequest at X
   with {A, B, C}.
4. Management server treats the X DiscoveryRequest update as a NACK
   for the X+1 DiscoveryResponse.

api/discovery.proto

@@ -43,6 +43,11 @@ message DiscoveryRequest {
   // in requests made via singleton xDS APIs such as CDS, LDS, etc. but is
   // required for ADS.
   string type_url = 4;
+  // nonce corresponding to DiscoveryResponse being ACK/NACKed. See above
+  // discussion on version_info and the DiscoveryResponse nonce comment. This
+  // may be empty if no nonce is available, e.g. at startup or for non-stream
+  // xDS implementations.
+  string response_nonce = 5;
 }
 
 message DiscoveryResponse {
@@ -65,4 +70,13 @@ message DiscoveryResponse {
   // Any messages for resources if resources is non-empty. This effectively
   // identifies the xDS API when muxing over ADS.
   string type_url = 4;
+  // For gRPC based subscriptions, the nonce provides a way to explicitly ack a
+  // specific DiscoveryResponse in a following DiscoveryRequest. Additional
+  // messages may have been sent by Envoy to the management server for the
+  // previous version on the stream prior to this DiscoveryResponse, that were
+  // unprocessed at response send time. The nonce allows the management server
+  // to ignore any further DiscoveryRequests for the previous version until a
+  // DiscoveryRequest bearing the nonce. The nonce is optional and is not
+  // required for non-stream based xDS implementations.
+  string nonce = 5;
 }