Context parameters in UDPA URIs embedded in server returned resources

The treatments of [context parameters](https://docs.google.com/document/d/1zZav-IYxMO0mP2A7y5XHBa9v0eXyirw1CxrLLSUqWR8/edit#heading=h.nnqgti1ico3k) in [xDS transport next steps](https://docs.google.com/document/d/1zZav-IYxMO0mP2A7y5XHBa9v0eXyirw1CxrLLSUqWR8/edit) indicates that client context parameters, e.g. node metadata, are unconditionally included in URIs placed in discovery requests.

This makes sense for URIs that originate at the client, e.g. those found in a bootstrap file, but not so much for URIs provided in server returned resources, e.g. a RDS URI in an LDS response. In the server returned URI case, we should not force the client to have to include potentially irrelevant metadata. There are multiple rationales for this:
* This reduces the amount of noise in and size of URIs when the node metadata is irrelevant.
* Caching can be improved by not having to consider node metadata for resources where it's immaterial.
* This matches a RESTful style of resource management, which provides a well-understood division of responsibility.
* The server can always add the context parameters to URIs in returned resources based on the resources' URI context parameters if needed.

The only potential downside is that the server may need to do some additional work in generating embedded URIs when it is necessary to propagate node metadata context parameters to resource dependencies.

I'd like to propose an addendum to [xDS transport next steps](https://docs.google.com/document/d/1zZav-IYxMO0mP2A7y5XHBa9v0eXyirw1CxrLLSUqWR8/edit) where we limit per-node client capabilities (and possibly client feature capabilities) to URIs that originate on the client.

@markdroth @louiscryan @howardjohn @costinm @mattklein123 @envoyproxy/udpa-wg

Start by reading the linked xDS transport next steps document and the linked context-parameters document, then review the discussion on this issue. Define the proposed addendum limiting client context parameters to client-originated URIs; done means the specification change is clearly documented and agreed by the working group.

Written by the indexing model from the issue text.