internal/grpc: move filtering of Values to Register

[davecheney]

Currently the grpc package and xds handler can filter results returned by cache.Values by a filter constructed from the DiscoveryRequest. However the cache.Register method lacks a way of filtering notifications and thus registers for all changes to the cache. This mean when the channel passed to Register fires, the update may not match the filter supplied and the result is a noop.

This is better than #350, but has lead to at least two issues, #363 and #420, and possibly others.

[phylake]

Is this the cause of the N^2 behavior we're seeing on EDS updates? For every EDS DiscoveryRequest we're pretty sure the entire EDS config is being sent back

[phylake]

EDS is the only xDS that will benefit from this right? It feels like #1166 and #1172 but with a bit different description. Also, I'd still appreciate a response to my previous comment.

[stevesloka]

@phylake solving #1166 & #1172 I think will drastically reduce the number of updates overall on a busy cluster. I'm not personally 100% certain the answer to the n^2 behavior you are referencing, so I don't want to give a guess for a response.

[davecheney]

EDS updates are now filtered by the resource hint that envoy provides in its discovery request.

[davecheney]

Nothing more is planned for this issue before 1.0. Moving to the backlog